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Preface 


In this book, a variety of algorithms are described that may be of interest to 
everyone who writes software for 3D-graphics. It is a book that has been written 
for programmers at an intermediate level as well as for experienced software 
engineers who simply want to have some particular functions at their disposal, 
without having to think too much about details like special cases or optimization 
for speed. 


The programming language we use is C, and that has many advantages, because 
it makes the code both portable and efficient. Nevertheless, it should be possible 
to adapt the ideas to other high-level programming languages. 


The reader should have a reasonable knowledge of C, because sophisticated pro- 
grams with economical storage household and fast sections cannot be written 
without the use of pointers. You will find that in the long run it is just as easy 
to work with pointer variables as with multiple arrays. 


As the title of the book implies, we will not deal with algorithms that are very 
computation-intensive such as ray tracing or the radiosity method. Furthermore, 
objects will always be (closed or not closed) polyhedra, which consist of a certain 
number of polygons. . 


Ray tracing algorithms are necessary to get highly realistic pictures, and it is 
even possible to make ray-traced movies out of complicated scenes. If you want 
to do that, however, you will need the fastest computers available on the market 
and an enormous amount of disk space. In order to create hundreds of frames on 
less sophisticated computers, we need different algorithms. The loss of realism is 
more than offset by the increase in speed. 
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Preface 


The method of the book is to introduce theoretical background and program- 
ming code at the same time. Type definitions, global variables and macros are 
described before their first applications. Because each chapter of the book builds 
upon the previous one, it is not advisable to skip any of them. If you are already 
familiar with a particular topic, at least skim over the relevant pages. All global 
variables, macros and function prototypes are listed in the index of the book. 


In summary, it may be said that the intention of this book is to 


@ provide a mathematical background for 3D-graphics. 


e gradually develop a complete graphics program that is able to render images 
of 3D-scenes comparatively quickly, including shadows and — to a limited 
degree — reflections. The images can be stored as PostScript files. The scene 
can be animated either interactively or by animation files. Series of scenes 
can be stored and replayed in real time. The program can be ported to any 
computer that is able to create palette colors by means of RGB-values and 
set pixels in those colors on the screen. The C compiler should provide a 
function to draw a line between two screen points and if possible a function 
to fill convex polygons. 


e illustrate techniques of C programming with emphasis on portability and 
speed. Readers who are not so familiar with the programming language C 
may also find this book useful for a better understanding of pointer arith- 
metic. 


e provide the reader with a source code of a graphics programming package. 
With the help of this source code, it is possible to adapt new code and 
to implement new information. (For example, one can easily introduce new 
spline types or new families of surfaces. ) 
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1.1 


1 


A Basic Course in Spatial 
Analytic Geometry 


In this chapter, we deal with the most common problems of analytic geome- 
try and present possible solutions for them. We also include an introduction to 
pointer arithmetic for programmers with little experience, so that they may be 
able to understand more complex things later on. 


If we do not start off with two-dimensional geometry, it is because we believe 
that, in reality, everyone is used to thinking in terms of spatial geometry and 
that speaking of objects in three-space does not necessarily make things more 
complicated. Furthermore, many principles of spatial geometry can also be ap- 
plied to two-dimensional geometry without any major changes. As a matter of 
fact, most of the problems mentioned in 1.1—1.4 have an equivalent in two-space 
(such as intersecting lines and measuring angles between lines), which can be 
solved by simply ignoring the third coordinate. Nevertheless, some specific two- 
dimensional problems will be dealt with in other chapters. 


Vectors 


Let us consider a three-dimensional Cartesian coordinate system based on the 
three pairwise orthogonal axes x,y,z (Figure 1). Each point P in space has 


unique coordinates pz, Py,Pz, and we write P(pz,py,pz). The vector p = OP 
from the origin O(0, 0,0) to the point P is called the position vector of P, and 
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we write 


Pr 
p= (Pz, Py) Dz) or p= Py |- (1) 
Pz 


The vector p may also be interpreted as a linear combination of the three pairwise 
orthogonal unit vectors that determine the unit vectors: 


1\ 0 0 
P=p.|0)]+p,{[1]+p.{[ 0]. (2) 
0 0 1 


Now let Q(dz,@y,Qz), with position vector g = (gz, @y,4z), be another point in 
space. The vector PO is then given by 


dx — Pz 


PO = | dy —py |, or more briefly, PO = q—Dp. (3) 
dz — Pz 
' ‘ 
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FIGURE 1. Cartesian coordinate system. 


The vector PO is called the difference between p and gq. An arbitrary point X 
with position vector z on the straight line PQ can then be given by the vector 


equation 

#=p+rAPQ (X real), (4) 
which, in combination with Equation 3, leads to the general equation of a straight 
line: 


€=(1—A)p+A_ (A real). (5) 
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The points P and Q correspond to A = 0 and A = 1, whereas any point in 
between those two corresponds to the values 0 < A < 1. 


Programming Techniques 


Let us now take a short break from theory in order to write a simple C function 
that allows us to calculate a point on the straight line PQ, depending on the 
parameter X. 


First of all, however, we want to say a few words about a programming technique 
we will use for our graphics package. 


The source code of a large program package should be split up into several 
modules main.c, filei.c, file2.c, file3.c, etc. The file main.c contains the 
main() function. 


The files will share several global variables. In general, we will try to avoid 
global variables whenever possible. They make large programs hard to maintain 
and create the potential for conflicts between modules. On the other hand, such 
variables may speed up the code. 


Global variables will be capitalized throughout this book. Thus, they can easily 
be distinguished from the local variables. We will put global variables into an 
include file named Globals.h. This file can then be included in the C code by 
writing 


#tinclude "Globals.h" 


All type definitions that are going to be used should be put into an include 
file Types.h. The same is true for all the macros that will be developed (— 
Macros.h). Macro names will be capitalized, too, so that we can distinguish 
them from functions. 


Finally, the function declarations (“function headers”) should be written in the 
include file Proto.h. Throughout this book we will use the standard C language 
defined by Kernigham/Ritchie (“K&R standard”) and not the more modern 
ANSI! Standard for the C language. 


Now the definitions are at our disposal whenever we need them. 


For more convenience, we put all the include files we need for our graphics 
package into a single include file 3d_std.h, which may then look like this: 


1“American National Standard Institute.” 
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/* The include file 3d_std.h */ 


#include "stdio.h" 
#include "math.h" 
#tinclude "Types .h" 
#include "Macros .h" 
#include "Globals.h" 
#include "Proto.h" 

# include "G_macros.h" 


(The system-dependent macros in G-_macros.h will be developed in Chapter 4.) 
At the beginning of each module we can now write 


#include "3d_std.h" 
and we do not have to worry about types or macros any more. 
For the global variables we use a little trick: we first define two macros 


H#ifdef MAIN (—> Macros .h) 
#t define Global 

# define Init(var, value) var = value 

#else 

# - define Global extern 

# define [nit(var, value) var 

#endif 


The file Globals .h looks somewhat like this: 


Global short Varl, Var2\6]; 

Global float Init( Var3, 1.0), Var4 [3]; 
Global char Init( Var5, ’s’); 

Global FILE Init(+F, stdout); 


In the file main.c, and nowhere else, the first statement is 
#define MAIN 


In this file the preprocessor now removes the word Global so that all the variables 
are declared in the usual manner. In any other module, the variables are declared 
extern. 


This technique, however, does not allow us to initialize arrays. ‘Thus, we write 


ifdef MAIN 
Global float Var4[3] = { 0.5, 1.5, —1 }; 


Helse 
Global float Var4 [3]; 


#endif 
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into Globals.h when we want to conveniently initialize arrays. 


The described technique is also very useful for the definition and initialization 
of pointers to functions: We define the macro 


#ifdef MAIN | (—> Macros.h) 
# define Init_fptr(ptr, function) (*ptr)() = function 

#else 

# define Init_fptr(ptr, function) (*ptr)() 

#endif 


and write all the pointers to functions at the end of the File Proto.h. A typical 
example is: 


Global Init_fptr(draw-_polygon, fill_poly); (—> Proto.h) 








After this introduction we can finally write our first C function. We introduce 
a new type of variable called Vector, which is meant to be an array of three 
real numbers. These numbers may be the space coordinates of either a point or 
a vector in our sense. C distinguishes between double precision (double) and 
single precision (float). Since single precision should be sufficient for most cases, 
we choose float so as not to waste any space. 


typedef float Vector [3]; (— Types.h) 
TT 
void point.on_line(result, p, q, lambda) (— Proto.h) 


Vector result; /* The point to be calculated. */ 
Vector p, q; /* The vertices. */ 
float lambda; /+* The parameter. */ 


{ /« begin point_on_line() */ 
register * float one_minus_lambda = 1 — lambda; 
register short 7; 
for (i =0; i < 3; i++) 
result[i] = one_minus_tlambda * pli] + lambda * q{t); 
}  /* end point_online() */ 


register variables speed up the code. They are just a suggestion, however, 
and whether the program really profits from them depends on the compiler that 
is used. 
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This would not be C if the same thing could not be written in quite a different 
manner with the use of macros. 


The use of macros helps to save time, considering that every call of a function 
takes time to copy variables into the stack. 


Another advantage is that with a macro the type of the variables is of no conse- 
quence, which means that if you prefer to use long or double instead of float, 
it will work as well. Thus, the C macro 


#define Point_on_line(result, p, q, lambda) \ (— Macros .h) 
(result|0] = p[0] + lambda * (q[0] — p[0]), \ 
result(1] = p[1] + lambda « (q[1] — p[1]), \ 
result|2] = p[2] + lambda * (q[2] — p[2])) 


has exactly the same effect as the previous function, with the only difference 
being that, in most cases, it will work a little bit faster because the preprocessor 
replaces every call of the macro by the corresponding code, without jumping into 
a function. It will also be faster because the counting variable 7 does not exist 
any longer. In addition to that, we use Equation 4 instead of Equation 5 because 
in every line there is only one multiplication instead of two - a subtraction can 
be done a bit faster! When we compared the calculation times, the results were 
that the function point_on_line() runs 30% to 60% more slowly than the macro 
Point_on_line(), depending on the computers and compilers that were used (see 
Appendix A.4). 


You may think that this obsession with speed is a little bit exaggerated, but 
you always have to keep in mind that the programming of 3D-graphics has to 
be extremely efficient in order to keep calculation times within limits. If we 
take every opportunity to save a little bit of time, the program as a whole will 
work much faster, which means that, in the end, we will be able to generate an 
animated picture 20 times a second instead of just 12 times a second. 


Macros can be quite tricky, though, which means that for the purposes of pointer 
arithmetic it is advisable to write (result) instead of result, (p) instead of p and 
(q) instead of g in the macro! The reason for this will be explained at the end 
of Section 1.4. Furthermore, it is always a good idea to protect the whole macro 
with parentheses (we will soon have an example of this). 


More About Vectors 
But now back to theory. A very important lemma is that two non-vanishing 


vectors @ = (az,a@y,a,) and % = (nz,nNy,nz) are perpendicular if and only if 
their so-called dot product vanishes: 


nad= | ny dy | =Nz Az + Ny ay +n, a, = 0. (6) 
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If # is to be normal to another vector 5 as well, its components have to fulfill the 
additional condition n, b, + ny by +n, b, = 0. The so-called cross product 


2 Ar ba a, b, — az by 
n=a@xb=]|a, |x | by | = | a2b,-a,bz (7) 
az by Az by — dy by 


is a vector that fulfills both conditions, and therefore, it is orthogonal to @ and b. 


Macros? for the dot product and the cross product might look like this (for better 
reading we define X, Y, Z first): 


#define X 0 (—> Macros.h) 

#define Y 1 

#define Z 2 

#define Dot_product(a, b)\ (—> Macros.h) 
((a)[X] * (6) [X] + (a)[¥] * (6)[¥] + (a)[Z] * (6)[2Z)) 

#define Cross_product(n, a, b)\ (—> Macros.h) 


((n)[X] = (a) [Y] * (6)[Z] — (a)[] + (6) ¥1, \ 
(n)[Y] = (a)[Z] * (6)[X] — (a)[X] + (6)[Z], \ 
(n)[Z] = (a) [X] * (®)[¥] — (@)[¥] + ()[X]) 


Again, the Vector variables should be written in parentheses for reasons of 
pointer arithmetic. Make sure that the whole expression is written in parentheses, 
too. Otherwise the expression 1 — @b will not be evaluated correctly by the 
expression 1 — Dot-product(a, b). 





FIGURE 2. A plane is determined by three points. 


3The reason why we use so many macros is explained in Appendix B.2. 
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In general, three points P,Q, R determine a plane (Figure 2). Any other point X 
on the plane can be expressed as a position vector Z, which is a linear combination 


of the vectors p, PO and PR: 


£=P+PO+r\2PR (A1,A2 real). (8) 


In order to eliminate the parameters 4; and A2g we simply multiply the vector 


equation by the normal vector 7 = PQ x PR, so that by Equation 6 we get the 
parameter free (or implicit) equation of a plane: 


nz = np =c= constant. (9) 


The constant c still depends on the length of the normal vector, which in turn 
depends on the points P, Q and R. For every point T (position vector t) in space 
that is not on the plane PQR, we have it 4 c. Two space points T; and T> lie 
on different sides of the plane if . 


sign(7it, — c) # sign(7t, — c). (10) 


The following function calculates the normal vector and the constant of a plane 
that is given by three points: 


#-define Subt_vec(AB, a, b)\ (— Macros.h) 
((AB)[X] = (6)[X] — (a)[X], \ 
(AB)[Y] = (®)[Y] — (@)[¥1, \ 
(AB)[Z| = (6)[Z] — (a)[Z}) 


typedef struct { 
Vector normal; 


float cnst; 
} Plane; (— Types.h) 
| 
void plane_constants(pqr, p, q, 7) (— Proto.h) 


Plane *pqr; /* Pointer to the struct Plane.‘ +/ 
Vector p, q, 7;° /* Three points on the plane. */ 


“One should always pass the address of a structure (“pass by reference” ) and 
not the structure itself (“pass by value”). A pass by value passes an entire copy 
of the structure. A pass by value guarantees that the function does not change 
the structure being passed! 

°A Vector is by definition an array, i.e., an address. This is different from 
PASCAL: if you pass an array in PASCAL, the program makes a copy of the 
entire array unless you use the keyword var! 
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{ /* begin plane_constants() */ 


Vector pq, pr; /* Difference vectors PQ and PR. * / 
register Vector *n = (Vector *) pqr—>normal; 
/* To speed up the macros. */ 


Subt_vec(pq, p, q); Subt_vec(pr, p, r); 
Cross-_product(*n, pq, pr); 
pqr-—>cnst = Dot-_product(*n, p); 

} /* end plane_constants() */ 


How to Measure Lengths and Angles 
If we want to measure the distance between two points P and Q, we simply have 
to measure the length of the vector d= PO = G—D: 


d;, 
dy 
d, 


Now we can normalize every non-zero vector d, which means that we scale the 
vector so that its length is one: 


|d| = = ,/d2 + d2 + d2 = Vad. (11) 








~ ry, [%/ id) | 
do = a= d,/|d| |. (12) 
| d,/\d 
A C subroutine for the normalization of vectors might look like this: 
#-define EPS le — 7 (— Macros.h) 
/* This very small number is quite useful! «/ 
#define Length(a) sqrt(Dot-product(a, a)) (—> Macros .h) 
void normalize_vec(v) (— Proto.h) 


Vector v; /* Pointer = Address => Contents of v will be changed! +/ 


{ /* begin normalize_vec() */ 
register float len; 
len = Length(v); 
if (len< EPS ) { 
print f("Cannot normalize vector\n"); 
return ; 


2X /= len; v[¥] /= len; v[Z] /= len: 
}  /* end normalize_vec() */ 


nn 
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This time it turns out to be more efficient to use a function instead of a macro, 
because now we can use one register variable several times. You will have noticed 
that within the function we do not need to write (v) instead of v. For the compiler, 
the variable v is in fact a pointer to a float. The components of the vector are 
changed when the program leaves the subroutine (this would not have been the 
case if the variable had not been a pointer!). 


With the help of normalized vectors, we can measure distances on given lines. 
For example, if we want to get a point R on the line PQ at a distance d from P, 
this point can easily be expressed by the equation 


—> 
?=ptd(PQ)o, (13) 
— 
where (PQ), is obtained by normalizing PO. Normalized vectors are also the 
key to the measuring of angles in space. If we want to measure the angle a of 
the two edges PQ and PR in Figure 2, we simply have to normalize the vectors 


d = PO and & = PR and calculate their dot product to get the cosine of the 
angle a: 


cos a= do Eo. (14) 


Additionally, we have 
sin a= do x é ; (15) 


though in most cases, we will prefer Formula 14 for reasons of speed. Every 
graphics programmer should avoid trigonometric functions, like sines, if possible. 
Unless you have an efficient mathematics coprocessor, such functions use up much 
more time than arithmetic operations. Fortunately, it is frequently possible to 
avoid those functions. An example is Lambert’s cosine law, which says that the 
brightness of a polygon (a face of the object we intend to create) mainly depends 
on the cosine of the angle of incidence of the light rays. Thus we will do the 
following: 


Before any drawings are begun, we determine and normalize the normal vectors 
of all faces. The cosine of the angle of incidence of a facet equals the dot product 
of the normalized normal vector and the normalized light ray.© The angle itself, 
however, does not have to be calculated because of Lambert’s law. In this manner, 
we are able to avoid the function arccos() for each facet of our scene. 


°In fact, this is only true when the light rays are parallel. Otherwise the angle 
of incidence will be different for each point of the face. An “average angle of 
incidence” might be the angle of incidence of the light ray through the barycenter 
of the polygon. This point can be precalculated before any drawings are begun. 
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In order to determine the angle between a plane and a straight line, we measure 
the angle between the line and the normal of the plane and subtract the result 
from 7/2. The angle between two planes equals the angle between the normal 
vectors of the planes. 


Intersections of Lines and Planes 


° e . e . ~ - —_~ 
Let a straight line AB be given by its parametric equation £ = @ + A AB and 
a plane be given by the implicit equation 7 Z = c. (We have already developed 
subroutines to get the values of 7 and c). Now the intersection point S has to 


fulfill both conditions, and we have 7 (@ + A AB) = c. Therefore, the parameter 
value for S is 


~ 


_c—na 
ni AB 
Let us look at the source code of a corresponding C function: 


#-define INFINITE 1¢20 (— Macros.h) 
#:define Linear_comb(r, p, pq, l)\ (— Macros.h) 


((r)[X] = (p)[X] +1 * (pq)[X], /* Similar to Point_on_line(). «/\ 
(r)[Y] = (p)[¥] +1 *(pq)[¥],\ 
(r)[Z] = (p)[Z] +1 * (pq)[Z]) 


typedef char Bool; (— Types .h) 
/* Possible values TRUE and FALSE.” */ 

#ifdef TRUE 

# undef TRUE 

#tendif 

#ifdef FALSE — 

# undef FALSE 

#endif 

#+:define TRUE (Bool) 1 (— Macros.h) 

#-define FALSE (Bool) 0 


#:define Is_zero(x) (fabs(x) < EPS ) (— Macros.h) 


A 





(16) 


In C no type Bool is defined. The smallest fast-accessible type of a variable 
is char, which can still be assigned to the values —128 to +127. There will be 
no warning if you assign an arbitrary number to a Bool variable. Nevertheless, 
we will only assign TRUE and FALSE. These two values have to be (re)defined. 
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| 
void sect_line_and_plane(s, lambda, parallel, a, ab, p) (— Proto.h) 


Vector s; /* Intersection point. «/ 

register float +lambda; /+* Parameter to intersection point. */ 
Boolsparallel; 

Vector a, ab; /* Point on line, direction of line. */ 

Plane xp; 


{ /* begin sect_line_and_plane() */ 
register Vector *n = (Vector *) p—>normal; 
/* To speed up the macro. */ 
float n_ab; 


nab = Dot_product(«n, ab); 

if ([s_zero(n_ab)) { 
/* Either the line coincides with the plane or it is parallel to the plane. 
*/ 
*xparallel = TRUE; 
if (Is_zero( Dot_product(*n, a) — p—>cnst)) *lambda = 0; 
else *lambda = INFINITE: 

} else { 
xparallel = FALSE; 
+lambda = (p—>cnst — Dot_product(*n, a)) / nab; 

} /* end if (Is_zero()) */ 

Linear.comb(s, a, ab, *lambda); 

} /* end sect line_and_plane() */ 


For less experienced C programmers: if we want to have the variables lambda and 
parallel at our disposal outside the function, we have to pass them as pointer 
variables, because C “calls by value” (in PASCAL you would have to write the 
keyword var before the variable in the argument list). A pointer variable ptr to 
a float, for example, is declared by float *ptr. The pointer ptr itself is then the 
address of the variable +ptr. The pointer can only be changed within a function, 
whereas a change of its contents *ptr will also be effective outside of it! 


When calculating lambda, we had to make sure that there was no division by 
zero. It will occur when the direction of the line is parallel to the plane. In this 
case, A is oo or it is not defined, if the point on the line coincides with the plane. If 
we now let \ = INFINITE or \ = 0, the “intersection point” will be somewhere 
far out on the line or it will be the initial point itself, which is fine. Computer 
scientists prefer unconventional solutions like this one, rather than having to 
distinguish between several different cases. The flag parallel is set additionally 
in order to let us know when a special case has occurred. 
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Next we need to know how to intersect two straight lines within a plane. The 
two lines may have the parametric equations 


~ 


#=G+Ad, %=b+pyé with &= (ez,e,,e,). (17) 


Now we intersect the lines by symbolically writing Z| = £2. When é is parallel 
to the z-axis (e, = 0 and e, = 0) (and when d is not parallel to the z-axis), we 
have 


‘252 if d, £0; 
=| a 4 (18) 


“re otherwise. 

When é is not parallel to the z-axis we multiply the vector equation 2, = Z2 by 

the vector vip = (—ey, ez, 0), which is normal to &, according to Equation 6, and 
we get 

@iie + Adie = bike, (19) 


so that the parameter 2 can be evaluated directly: 


_~ 


(b— a) ie 
di. 


A= (20) 


When the lines are parallel or identical, we have |d7i.| < EPS. In this case, we 
let A = o0, if the nominator is not zero, or A = 0, if the nominator is zero. 


Here is a C function to accomplish the task: 


First some two-dimensional equivalents to previous definitions: 


typedef float Vector2 (2); (— Types.h) 
/* A two-dimensional vector. */ 

#define Subt_vec2(ab, a, b)\ (— Macros.h) 
((ab)[X] = (6)[X] — (a)[X], (ab)[¥] = (6)[ ¥] — (@)[¥]) 

#-define Dot_product2(a, b)\ (— Macros.h) 
((a)[X] * (6) [X] + (a) ¥] * (0) Y)) 

#define Linear_comb2(r, p, pq, !)\ (— Macros.h) 


((r)[X] = (p)[X] +1 * (pq)[X], \ 
(r)[Y] = (p)[¥] +l * (pq)[Y)) 


#-define Parallel_z(v)\ (— Macros.h) 
(Is_zero((v)[X]) && Is_zero((v)[Y])) 
#define Normal_vec2(n, v)\ (— Macros.h) 


((n)[X] = —(»)[¥], (»)[Y] = (v)[X]) 


14 Chapter 1. A Basic Course in Spatial Analytic Geometry 


| 
void intersect_lines(s, lambda, parallel, a, d, b, e, dim) (— Proto.h) 
float s| |; 


/* Intersection point. The reason why we use an array of floats instead of 
the types Vector or Vector2 is because this function works without 
any changes when the vectors a, b, d, e in the argument list are two- 
dimensional! (Both Vector and Vector2 are interpreted as pointers to 
a float.) The only difference between a 2D-version and a 3D-version is 
in the calculation of the intersection point. +/ 

float +lambda; 

/* Parameter A of the intersection point of the lines 
E=G+Ad=b+ pe. +/ 

Bool «parallel; 

float a[], d[], [], ef]; 

short dim; /* 2D or 3D. */ 


{ /* begin intersect_lines() */ 
Vector2 ne, ab; 
float d_ne, ab_ne; 


if (dim == 3 && Parallel_z(e)) { 
if ((*parallel = Parallel_z(d)) ) { 
if (a[X] == 0[X] && al[Y] == B[Y]) +lambda = 0; 
else *lambda = INFINITE; /* Lines are parallel. */ 
} else if (!Is_zero(d[X])) *lambda = (b[X] — a[X])/d[X); 
else if (!Is_zero(d[Y])) +#lambda = (b[Y] — alY])/d[Y]; 
}else { /* &is not parallel to the z-axis. +/ 
/* Because of ne[Z] = 0, it is enough to make some 
of the following calculations only two-dimensionally. */ 
Normal_vec2(ne, e); 
d_ne = Dot_product2(d, ne); 
Subt_vec2(ab, a, b); 
abne = Dot_product2(ab, ne); 
if ((*parallel = Is_zero(d_ne)) ) { 
if (Is_zero(ab_ne)) +lambda = 0; 
else *lambda = INFINITE; 
} else { /* This is the general case at last. «/ 
+lambda = ab_ne/d_ne; 
} /* end if (Is_zero(d_ne)) */ 
} /* end if (€ parallel z)) +/ 


if (dim == 2) 
Linear .comb2(s, a, d, +lambda); 
else 


Linear_comb(s, a, d, lambda); 
} /* end intersect_lines() «/ 
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For some hidden line determinations (Section 7.2) we need another function 
inter sect_segments() that is related to the function intersect_lines(). It cal- 
culates both the parameters ¢; and t2 from the equation p, + t1(p2 — pi) = 
Gi + te(q2 —q) (and nothing else). When the segments are parallel (or identical) 
the function returns FALSE, else it returns TRUE. 


Re ee a ae ee ee 
Bool intersect_segments(tl, t2, pl, q1, p2, q2) (— Proto.h) 
float *t1, *t2; 
float pl[ |, q1[]; /* The first segment. */ 
float p2[ |, q2[]; /* The second segment. */ 


{ /* begin intersect_segments() */ 
Vector2 dirl, dir2, plp2; 
Vector2 n1, 72; 
double det; 


Subt_vec2(dir1, pl, q1); Subt_vec2(dir2, p2, q2); 
Normal_vec2(n1, dir1); Normal_vec2(n2, dir2); 
det = Dot_product2(dir1, n2); 
if (fabs(det) < EPS) return FALSE; 
Subt.vec2(plp2, pl, p2); 
*tl1 = Dot_product2(p1p2, n2) / det; 
*t2 = Dot_product2(plp2, n1) / det; 
return TRUE; 

} /* end intersect_segments() */ 





FIGURE 3. The line of intersection of two convex polygons. 


The intersection of two planes can be achieved by the intersection of two lines of 
the first plane with the second plane. Since we do not usually deal with infinite 
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planes, but rather with polygons that span the plane, we want to solve an addi- 
tional problem: given two convex polygons (usually triangles or quadrilaterals) 
that intersect each other as in Figure 3, we look for the end points S; and S2 of 
the intersection, which is a straight line. 


Provided that such a line of intersection exists, we will always be able to find 
exactly two edges on the first polygon that intersect the plane of the second 
one. The two intersection points may be called 7;,7>. The line joining them is 
represented by the parametric equation 


@=t,+A(-h) (A real). (21) 


The point 7; corresponds to the parameter value = 0, the point T> corresponds 
to the value A = 1. Now we determine the edges of the second polygon, the 
vertices of which lie on different sides of the plane that is determined by the first 
polygon, and we intersect them with the edge 77>. These intersection points 
may be called Ui; and Us, and they belong to two parameter values A, and Ag. 
We finally modify these values 


0, if A; < 0 (=> S; = T;); 
M= 4A, O<A <1 (=> S;= U;); (t = 1,2) (22) 
1, ifd; 21 (= S$; =T2); | 


and have the parameter values of the end points S;, S_ of the actual line of 
intersection. 


Here is the corresponding C code: 


#-define Swap(a, b) (temp =a, a =b, b = temp) | (— Macros.h) 
#-define Sign(x) ((x < 0) ? (—1): (1)) (— Macros.h) 
#-define Which_side(point, plane)\ (— Macros .h) 


Sign(Dot_product((plane).normal, point) — (plane).cnst) 


Bool sect_polys(section, n1, polyl, n2, poly2) (— Proto.h) 
Vector section[2]; /* Intersection points. +/ 
short nl, n2; /* Number of vertices of the (convex!) polygons. */ 
Vector poly1[ ], poly2[ ];? /* Vertices of the polygons. «/ 


®This gives us the chance to explain the different writings we can use when 
we pass an array 2 as a function argument. The compiler will convert your 
writing into the pointer +z in any case. Thus, it does not make any difference 
whether you really pass a pointer or the start address of an array. For better 
reading, however, it is preferable to write z[ ] or, when the size of the array is 
constant, x|size]. The compiler uses the size information only for bounds-checking 
(provided that it supports that feature). 
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{ /x begin sect_polys() */ 
register short i, J; 
Plane planel, plane2; 


Vector t[2); /* Ti, T> */ 


Vector t1t2; /* TT) */ 
float lambda|2]; /* Parameters to section points. */ 


Vector plp2; /* Difference vector. */ 
short sidel, side2; /* Which side of the plane? +*/ 


short found = 0; 
Bool parallel; 


/* First calculate the intersection points T,, T> of 
the first polygon with the plane of the second polygon. */ 
plane_constants(&plane2°®, poly2(0|, poly2[1], poly2[2}); 
side2 = Which_side(poly1(0|, plane2); 
for (i =0, 7 =1;7 < nl; i++,j4++4+){ 
if(j == nl) j =0; 
sidel = side2; 
side2 = Which_side(poly1|j], plane2); 
if (sidel |= side2) { 
Subt_vec(p1p2, poly1|{i], poly1|7]); 
sect_line_and_plane(t| found], &&lambda| found], &parallel, 
polyl[i], plp2, &plane2); 
if (lambda| found|>=0 && lambda|found|<=1) 
if (++ found == 2) 
break; 
} /* end if (stdel) «/ 
} /* end for (2) */ 
if (found < 2) 
return FALSE; /* No line of intersection. */ 


/* Now we intersect the line T;T> with the edges of the second polygon. */ 
plane.constants(&planel, poly1[0], poly1[1], poly1[2}); 
found = 0; 
Subt_vec(t1t2, t[0], t{1]); 
_side2 = Which_side(poly2|0|, plane1); 
for (¢ =0, j =1,7 < n2;i14+4+, j++) { 
F(j == n2) 7 =0; 
sidel = side2; 
side2 = Which_side(poly2|j], plane1); 
if (sidel!=side2) { 
Subt_vec(p1p2, poly2[i], poly2[j]); 
inter sect_lines(section, &lambda[ found], &parallel, 
t[0], £12, poly2[i], plp2, 3); 
/* Modify parameter. */ 


°For less experienced C programmers: we have to pass the argument plane? 
as a pointer to a Plane. This is done by passing its address (= &plane2). 
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1.4 


if (lambda[found] < 0) 
lambda| found] = 0; 
else if (lambda[found| > 1) 
lambda|found] = 1; 
if (++ found == 2) { 
if (lambda|0| > lambda[1]) { /* Sort parameters. */ 
float temp;'° /* Necessary in the Swap macro. */ 


Swap(lambda[0|, lambda/[1)); 
} /* end if (lambda) */ 
break; 
} /* end if (found) «/ 
} /* end if (side1) */ 
} /* end for (2) */ 
if (lambda[1] — lambda[0] < EPS) /* Line too short. +/ 
return FALSE; 
/* Determine the actual intersection points. +/ 


Linear_comb(section|0], t[0], t1¢2, lambda[0}); 
Linear_comb(section|1], t[0], t1¢2, lambda|[1]); 
return TRUE; 

} /* end sect_polys() +/ 


Translations 


By adding a translation vector ¢ to the position vector of a space point we get 
the position vector of the translated point. Usually, translations are applied to 
hundreds or even thousands of points. Therefore, we want to have a subroutine 
that is able to accomplish the task as quickly as possible. With the help of 
pointer variables we can keep the coordinates of related points together in one 
storage block, which we will call a “pool.” Let us have a look at the procedure 
in question: 

#-define Add_vec(result, a, b)\ (— Macros.h) 

((result)[X] = (a)[X] + (6)[X], \ 


(result)[Y] = (a)[Y] + (®)[YI, \ 
(result)[Z] = (a)[Z] + (6)[Z]) 


1°C is very flexible in the declaration of variables. Sometimes programs become 
more readable when variables that are needed only in smaller loops etc., are 
declared locally. Such variables, however, cannot be used as register variables. 
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[Dee ee ee ee SS ee 
void translate_pool(n, pool, trans) (— Proto.h) 


short n; /* Number of points to be translated. */ 
Vector «pool; /* Coordinate pool of arbitrary size. +/ 
Vector trans; /* Translation vector. +/ 


{ /* begin translate_pool() «/ 
register Vector «vec = pool, *hivec = vec+n; 


for (; vec < hi_vec; vec++) 
Add_vec(*vec, *vec, trans); 
} /* end translate_pool() */ 


The pointer vec is a pointer to a Vector, thus hi_vec = vec+n is a pointer to 
a new Vector *hi_vec. In between vec and hi_vec there is space for n vectors. 
Because of the scaling nature of pointers in C [DARN88] they can be evaluated 
by means of 

#vec = #(vec+ 0), *(vec+ 1), *(vec+ 2), etc. 





Val ues fever] [2] ¥ vec! 2] 


FIGURE 4. The difference between the evaluations of (*vec)[2] and *vec(2], where 
vec is a pointer to a Vector. 


Once again, we have an example of a macro where it is important to write the 
arguments in parentheses. In C (*vec)[2] is not the same as *vec[2]. The compiler 
will interpret the first expression as (*vec)[2] = **vec + 2, ie., as the z-value of 
the Vector *vec, which is correct. The second expression will be interpreted as 
*vec(2] = **(vec + 2), which is the z-value of the vector +(vec+ 2)!1! For better 
understanding see Figure 4. Pointer arithmetic may seem to be tricky, but after 
some time you will discover that it is one of the greatest things in C and that it 
speeds up the programs amazingly. If you look at the previous function again, 
you will see that almost all the calculations are done with register variables. 


"vec is a Vector, i.e., a pointer to a float, *«vec is a float! 
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Additions with such variables are probably among the fastest things a computer 
can do. There are no function calls, because Add_vec is a macro. If your computer 
is able to work with more than two register variables and if you have huge pools 
to transform, it may be worth declaring another variable 


register Vector *t = (Vector *) trans; 


Now write 


for (; vec < hi_vec; vec++) 
Add_vec(*vec, *vec, +t); 


Matrices 


Before we talk about rotations in space we will say a few words about matrix 
calculus, which is a very convenient way of abbreviating long and confusing 
calculations. In this context we will only speak of square 3 x 3-matrices. Such 
a matrix is an array of nine numbers (called elements) in three rows and three 
columns. The elements in a row may be interpreted as a vector (“row vector” ). 


Let A and B be two 3 x 3 matrices: 


“A00 «401 «02 boo 001 502 
A=(aiy%)=[ Q10 @1 G2}, B=(bi%)= | bio 01 512 |. (23) 
Q20 421 422 boo = ba3 a2 


The product of the matrices is defined as 
AB=C= (Cik) with cj, = aio DoK + Gi b1~ + Ai2 box . (24) 


Note that AB 4 BA. The product of a vector U = (vz, vy,vz) and a matrix A 
is defined as a new vector r: 


Uz A909 + Vy 419 + Vz A20 
P=VA= | vz 491 + Vy Q11 + Vz aa |. (25) 
Uz G02 + Vy 212 + Vz A22 


Note the order of the operands in the multiplication. In many (especially in 
European) books, column vectors are used instead of row vectors and the order 
is turned around (Av instead of vA). In this case the matrix A has to be 
“transposed” into a matrix A’ (Equation 26), i.e., its elements are reflected on 
the so-called main diagonal. 


Every rotation in space by an arbitrary angle about an axis running through the 
origin can be described by a so-called orthogonal matrix or rotation matrix. The 
row vectors of such matrices are all normalized and pairwise orthogonal. The 
product of two rotation matrices is also a rotation matrix. 
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Because of the special properties of a rotation matrix we get its inverse matriz 
simply by transposing it: 


1 r G00 @10 420 
AU =A‘ = 201 @11 4921 . (26) 
Q02 @12 422 


If A is a rotation matrix that describes the rotation of space by an angle y about 
an axis a, its inverse matrix causes a rotation about the same axis a, but by the 
opposite angle —y. 

Let us now have a look at the corresponding C code. First we define a new type: 
typedef float Rot _matrix(3]/3); (— Types .h) 


A subroutine for a matrix multiplication might look like this: 
void matriz_mult(c, a, b) (for the time being!) 

Rot_matrix c, a, 5b;!” 
{ /* begin matrix_mult() */ 

register short 7, 7; 

for (i =0; i < 3; i++) 

for (j = 0; j < 3; j++) 
clé|[9] = ale] [0] * b[0][9] + afé)[1] * b[1][3] + afé][2] + b[2][7); 

} /* end matriz_mult() * 


The multiplication of a vector by a matrix is done by means of the function 
void vec_mult_matriz(result, v, a) (for the time being!) 
Vector result; 
Vector v; 
Rot_matrix a; 
{ /* begin vec-mult_matriz() «/ 
register short 1; 
for (¢ =0; i < 3; i++) 
result|i] = v[X] » a0] [é] + o[¥] « a[1][¢] + v[Z] * a[2] [4]; 
} /* end vec_mult_matriz() */ 
Now we will try to speed up this function, for which purpose we use pointers to 
Vector variables: 
##define Vec_mult_matriz(r, v, m)\ (— Macros.h) 
(r)[X] = (v)[X] * (m)[0][0] + (v)[¥] * (m)[1] [0] + (v)[Z] + (m)[2][0], \ 
(r)[Y] = (v)[X] * (rm) [0][1] + (v)[¥] * (mm) [1][1] + (v)[Z] + (m) [2] [1], \ 
(r)[Z] = (v)[X] * (m)[0][2] + (v)[¥] * (m)[1][2] + (v)[Z] « (m) [2] [2] 
/* Faster version. */ 


“The type Rot_matrix is by definition a pointer. Therefore, the changes of 
the argument c will be valid outside the function. 
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void vec_mult_matriz(result, v, a) (— Proto.h) 
Vector result; 


Vector v; 
Rot_matrix a; 


{ /* begin vec_-mult_matriz() */ 
register Vector «res = (Vector *) result, «vec = (Vector *) v; 


Vec_mult_matriz(*res, *vec, a); 
} /* end vec_mult_matriz() */ 


In a similar way, we accelerate matrix multiplication. 


/* Faster version. */ 


void matriz_mult(c, a, b) (— Proto.h) 
Rot_matrix c, a, 5; 


{ /« begin matriz_mult() */ 
register Vector 
#vec = (Vector *) a, 
*hivec = vec + 3, 
#res = (Vector *) c; 
for (; vec < hi_vec; vect++, res++) 


Vecmult_matriz(+res, *vec, b); 
} /* end matriz_mult() */ 


1.6 Rotations 


A rotation of a point P about the z-axis by the angle ¢ is done by the multipli- 
cation of its position vector p by the rotation matrix 


cos ¢ sing Q 
Z(¢)= |} —sin¢ cos ¢ 0]. (27) 
0 0 1 


By convention, a rotation angle is declared to be positive if it appears as a 
positive angle when we “look into” the oriented axis. 


When we rotate the unit point £,(1,0,0) on the z-axis about the positive ori- 
ented z-axis by 7/2, it will coincide with the unit point E,(0,1,0) on the y-axis. 
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In order to rotate P about the oriented z-axis by the angle €, we multiply its 
position vector by the matrix 


1 0 0 
X(€)= {0 cosé sin €é }. (28) 
0 -sin€ cos & 


This time the unit point E, on the y-axis will coincide with the unit point 
E,(0,0, 1) on the z-axis if we rotate it by € = 7/2. 


Finally, the rotatzon about the oriented y-axis by the angle 7 is achieved by a 
multiplication of the position vector by 


cos 7 0 —sin 7 
Y(n) = 0 1 0 (29) 
sn 7 0 cos7 


Note the signs of cos and sin in this case! As a result, FE, will coincide with E, 
when we rotate it by 7 = 7/2. 


Now we want to rotate a point about an arbitrary azis g through the origin by 
the angle y. This can be done by a multiplication by a single general rotation 
matrix R, the elements of which may be determined by the following geometric 
considerations (Figure 5): 
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FIGURE 5. Rotation about a general axis. 


ty 


Let the rotation axis g be the z-axis of a new Cartesian coordinate system L, 
with the three pairwise orthogonal unit vectors é€, f and g. 


For the unit vector g, we choose the normalized direction (gz, 9,92) of the axis 
g. Next we choose the horizontal normal vector (—g,, 92,0) of g and normalize 
it. Thus, we have found a second unit vector € = (€z, ey, €z). (If gr = gy = 0, we 
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let & = (1,0,0).) Finally, the unit vector f = (fz, fy, fz) is the cross product of 
the two vectors: f =gxé. 


Consider a rotation matrix M that describes the rotation of space so that the 
axes of , will coincide with the axes of the original system. By means of this 
matrix the rotation about g is transformed into a rotation about the z-axis, 
which we can already handle. The rotation back to the system , is described 
by the inverse matrix M~!. Thus, we have 


R=M Z(y)M*. (30) 


The inverse matrix M~ can be determined easily. It is nothing but the rotation 
matrix 


Cz Cy Cz 
M'=|{f. fy fe]- (31) 
Gx Qy Jz 


To prove this, we simply have to apply the rotation described by M -1 to the unit 
vectors of the original system. The rotated vectors are indeed é, f and g. Finally 


we come to the general case of a rotation about an arbitrary azis. If a is the 
position vector to a point A on the axis, we first translate the points that have to 


be rotated along the vector —@ = AO; then we apply the rotation (Equation 30) 
to the translated points, and finally, we translate the points back by means of 
the vector d. 


2 


Projections 


From the physical point of view, one-eyed seeing is nothing but projecting three- 
dimensional objects onto a projection surface (projection plane) by means of a 
lens (the camera lens or the lens of the eyeball). The brain is then more or less 
capable of “reconstructing” the objects in space, i.e., of estimating the distance 
of the objects with the help of size comparisons or shadows. Misinterpretations 
are reduced by two-eyed seeing, because it enables the brain to intersect corre- 
sponding projection rays in space. 


Geometrists distinguish between central projections (where the projection center 
is not at an infinite distance) and parallel projections. In reality, most projec- 
tions are central projections (“perspectives”). For technical drawings we will 
mainly use “orthogonal projections” as a special case of parallel projections. 
Among these projections there are the “main views” (the top/bottom view, the 
front /back view, the right-hand side/left-hand side view) and axonometric views. 
Such projections permit us to compare or even measure lengths and to determine 
whether lines in space are parallel or not. 


Since parallel projections can be interpreted as extreme cases of central projec- 
tions, we will only talk about central projections in this book. 








In this chapter we will learn how to deal with projections and how to submit the 
process of illumination to the rules of perspective. Furthermore, we will develop 
functions and macros that allow us to switch between different coordinate sys- 
tems as quickly as possible. Finally, we will develop C functions for the clipping 
of lines and polygons. 
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2.1 Central Projections 


A central projection is determined by the projection center C' and the principal 
point T (“target point” or “look-at point”). The image plane 7 is defined as the 
normal plane to the “principal ray” CT through the principal point (Figure 1). 





FIGURE 1. “World system” and “screen system.” 


The distance d = \CT | is called the distance of the perspective. This is the general 
case of a central projection. The camera itself may be rotated (“twisted”) about 
the main projection ray by an angle 7. (The angle 7 is measured with respect to 
the horizontal normal vector to the projection ray.) 


In order to make the image plane 7 become the base plane xy, we now transform 
all the points that have to be projected so that 

(1) the principal point T becomes the origin of the coordinate system, 

(2) the projection center C becomes a point on the positive z-axis, 

(3) the twist angle 7 is eliminated. 


Figure 2 illustrates what we have to do. In order to fulfill condition (1), we 


only have to apply a translation by the vector TO to all the points and to the 
projection center as well. To fulfill condition (2), first we rotate the translated 
world system about the z-axis until the translated projection center C*(cz, cy, cz) 
lies on the yz-plane. According to Figure 2a, the rotation angle —7 is een by 


= if cp > 0; 


5 t+(arctan +7), otherwise. 


= + arctan Sy 
1= (-17<y<7) (1) 
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ae 






The translated : B (c) rotated about 


screen system is | the z-axis by —a. | 


(a) rotated about 


(b) rotated about 
the z-axis by —7, 


the z-axis by —/, 






— Se aa y | 


FIGURE 2. A transformation of the projection center and the image plane. 
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Now the image plane contains the z-axis. Thus, if secondly we rotate about the 
z-axis by the angle —6 


@ = arccos + (0<B<n) with d=4/c.?2+¢?+¢,%, (2) 


the image plane will become the xy-plane (Figure 2b). In order to eliminate 
the twist-angle (condition (3)), we finally rotate the transformed points about 
the transformed principal ray, which coincides with the z-axis, by the angle —a 
(Figure 2c). : 


=T (-1t™<a<n). (3) 
All three rotations can be performed in one step, which is described by the matrix 
R = Z(—7) X(—£) Z(-a). (4) 


A point P(pz,p,,pz) with position vector p is rotated by means of R to a point 
P(p,,By,D,) with position vector Pp: 


"si 


= pR. (8) 


We have not yet projected the rotated points P to the image plane (i.e., the 
xy-plane). The new projection center, which now lies on the z-axis, has the 
coordinates C'(0,0,d). If we intersect the projection ray 


#= EF +A(P - 7), (6) 


with the plane z = 0, we get 





A=. (7) 


Thus, the image point P° of P has the two-dimensional coordinates 
Po =ADz, Py =ADy. (8) 
The z-coordinate p, of P is also the oriented distance Pz of the original space 


point P from the image plane 7. 


The three angles a, 3, y can be interpreted as Euler angles [FOLE90]. First we 
translate our objects so that the target point becomes the origin of the coordinate 
system. If we then rotate our objects 
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(1) about the z-axis by the angle a, 
(2) about the z-axis by the angle £, 
(3) once again about the z-axis by the angle 7, 


and if we finally project them from the point C(0,0,d) on the zy-plane, we will 
get the same perspective of our scene. The rotation matrix that performs all 
three rotations in one step is given by 


R~* = Z(a) X(6) Z(7). (9) 

This means that each perspective can be given by the equivalent parametriza- 
tions! 

(C, T,r) <=> (d, a, B, 7, T). (10) 


2.2 The Viewing Pyramid 





FIGURE 3. The “viewing pyramid.” 


The “neutral” or “vanishing” plane v, which is parallel to the image plane and 
which coincides with the center of the projection, divides the space into two 


‘No parametrization by three numbers, however, can _ continuously 
parametrize the space of rotations. In the (C,T,7r)-parametrization, for exam- 
ple, the angle 7 is ambiguous when the projection center is moved about during 
an animation and when CT points to the zdirection. 
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halfspaces. Of course it only makes sense to calculate the coordinates of images 
of those points that are in the halfspace that contains the image plane. Points 
in the other halfspace, however, may also play a part in the image of the scene. 
Imagine a polygon, some parts of which are in the visible halfspace and others in 
the “forbidden halfspace” (Figure 3). Nevertheless parts of the polygon have to 
be drawn. In this case, we have to calculate the intersection points with a “near 
clipping plane «,,,” which lies in between the image plane and the neutral plane 
v. Their images replace the “forbidden points” of the polygon. 





FIGURE 4. The neutral plane and the (near) clipping plane. The distance of the near 
clipping plane may have an influence on the appearance of the image polygons. 


In some cases, it may also be useful to introduce a “far clipping plane « f- 
(Figure 4). Objects that lie behind this plane are not drawn at all. Such a plane 
should be used for animations of complex scenes, in which some objects are 
temporarily far away from the observer. The computer would spend precious 
calculation time on the display of the images of such objects, even though these 
images are hardly more than pixel size. 


In general, we will not display objects that are outside the “viewing pyramid” or 
“viewing frustum,” which is formed by the near and far clipping planes and by 
those four clipping planes that are spanned by one side of the rectangular field 
of view and by the projection center (Figure 3). In Section 2.5, we will develop 
routines for the clipping of lines and polygons. 


An important question is which rectangle to choose for mapping on the screen. 
Figure 5 illustrates that it is a good idea to introduce a so-called “field-of-vision 
angle” 0° < » < 90°. 
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This is what we know of camera objectives with different focuses: a wide-angle 
lens has a greater field-of-vision angle than a telephoto lens. If you set up a 
camera, at a fixed point and take pictures of a scene first with a telephoto lens 
and then with a wide-angle lens, the only difference between these pictures will 
be the scale factor. Thus, if you enlarge a detail of the picture taken with the 
wide-angle lens, it will be identical to the corresponding one taken with the 
telephoto lens. 


Field-of-vision angles should not be too large (y < 60°) because our images would 
not look natural any more (Figure 6a). Small field-of-vision angles (y < 10°) 
create an impression similar to that of a telephoto lens (Figure 6c). For natural 
images, we can choose, for instance, 15° < y < 40° (Figure 6b). For parallel 
projections, we will let the distance of the projection center be “large,” but not 
infinite. Thus, we can still work with a “small,” but non-vanishing field-of-vision 
angle. 





FIGURE 5. The field-of-vision angle. 


Because many people are used to thinking in terms of focal distances f, we give a 
table of corresponding values,” valid for miniature cameras with a negative size 


of 24mm x 36mm ([HECH?74)). 
26.5° 38° 46° 53° 
46° 63° 75° 84° 
50mm | 35mm | 28mm |} 24mm 


yp 3.4° | 6.7° 13.4° 
G 6.2° | 12° 24° 
f || 400mm | 200mm | 100mm 


2The angle @ encloses the diagonal of the rectangular picture. 
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2.3 Coordinate Systems 


According to the results of Section 2.1, we will work with three different coordi- 
nate systems: 


1. The first system is the Cartesian “world system,” in which the coordinates 
of the vertices of our objects are given. 


2. The second coordinate system is the non-Cartesian three-dimensional 
“screen, system.” In this system, the coordinates of a space point are the 
ordinary screen coordinates of the image of the point (Equation 8), plus, as 
a third dimension, the oriented distance Z from the image plane 7a. 


3. As a third type of coordinate system, we introduce the non-Cartesian “light 
system,” which is similar to the screen system. In such a system a space 
point can also be described by the two-dimensional coordinates of its shadow 
(=projection) on an arbitrary image plane plus the distance of the point 
from this image plane as a third coordinate. 


When we talk about screen coordinates, we have to distinguish between the 
so-called screen coordinates on the image plane 7 (which are measured by or- 
thogonal unit vectors) and the “pixel coordinates,” which depend on the system 
that is used and which need not necessarily be normalized. Let us try to map 
the field —2 < 2° < 3, —-}3 < y° < % into the rectangular field 0 < u < w, 
0<v<h, where w and h are the width and the height of our graphics window. 
The linear functions 


u=— 2+ — ya cf (11) 
Uo 2’ 9 7 2 


will fulfill this task. If we are lucky, a polygon on the image plane 7 will then 
appear undistorted on the screen. On many systems, however, the polygon will 
appear distorted and/or be turned upside down. This can be avoided by intro- 
ducing a system-dependent variable go: 


wi. Ww h. ih 
Uu=—X2+—-—, v=0a(— —), 1 
Even though the screen coordinates x,y are now system-dependent, it is fairly 
easy to transform these “physical device coordinates” into “normalized device 
coordinates” 0 < 29, yo < 1 by means of the linear functions 


u v 
To= 7 Yo= oh (13) 
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FIGURE 6. The influence of the field-of-vision angle. 
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We will need such normalized coordinates for plotter drawings or for the output 
on other devices. 


According to the field-of-vision angle in Figure 5, the values of the variables uo 
and vo are: 


w —p 1 —p 
_ . — =o Le 14 
up = d tan =, Vo 07 a5 (14) 


The third dimension in the screen system (and in the light system) needs some 
more explanation. We will work with two transformations T; : P — P and 
T2.: P — P* of space, both of which will have the property that the normal 
projection of the transformed scene on the projection plane 7 is identical with 
the central projection of the scene from the projection center (light center). 


The first transformation 
T,: P(z,y, z) + P(&, 9, 2) (15) 


is non-linear. It is defined by 


Z=Az, p=Ay, Z=z2=Pxr with 4 = (16) 
Similary to T, the second transformation 
T2: P(z, y, 2) + P*(a*, y*, 2*) (17) 
is defined by 
z=An, y*=dAy, 27 =krAz with A= 7° (k real). (18) 


The transformation P — P* is a linear one, i.e., the transformed edges are still 
straight lines. (Such a transformation is called a collineation. The center of the 
collineation is the principal point.) To prove this, it is enough to show that a 
plane in space is transformed into a plane. A straight line is then the intersection 
of two planes. When three points P, Q, R are coplanar, we have 


Pr Py Dz 
D=/dz Qy Qz|=0. (19) 
T (Ty Tz 
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After the transformation T2, we have 


. Pr Dy Dz ApPz ApPy KAppz 
D™=/q, Gy Gz |= |Aqde Aqdy KAqgz | = kKApAGArD = 0. (20) 
rT. Ty r* Arf2 Arty KALTz 


Therefore, the three points P*, Q*, R* are coplanar as well. 


For k = 1/d, we have 





w= a (21) 
and the reverse transformation 
d z* 
= —_ 22 
2 1 + z* ( ) 


Regular points, i.e., points that are not in the forbidden halfspace, have z*-values 
in the interval —1 < z* < oo. For two points P and Q of the same halfspace, we 
have 


pt < qt <> pz < Dz: (23) 


Figure 7a illustrates the perspective projection of a roller. Figures 7b and 7c 
show two rather diverse spatial objects, the images of which are identical to the 
image in Figure 7a when we apply a normal projection to the picture plane 7. 
In Figure 7b, the transformation T, was applied. As we can see, the edges of the 
roller are not straight lines any more (they are slightly bent hyperbola arches, 
which indicates that the transformation is quadratic). In Figure 7d, the roller 
was transformed by transformation T2. 


When do we use which transformation? For our purposes it is enough to store the 
value z = p, (Ti) in the screen system and in the light systems. For intersections 
(e.g., for three-dimensional clipping or priority tests), however, we have to switch 
to the corresponding linear transformation T2 by transforming the z-values of 
the vertices of a point by means of the Formula (21). 


One of the advantages of the non-linear transformation T, is that it works per- 
fectly when the projection center is at an infinite distance, whereas the linear 
transformation would fail in such a case. 
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FIGURE 7. Different objects with identical images. 
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2.4 Back and Forth Between Coordinate Systems 


In this section, we will develop functions and macros that permit us to switch 
between all the systems as quickly as possible. The speed factor is quite essential 
here, because for every new frame these calculations have to be done thousands 
of times. 


Before we make any further calculations we translate our world system so that 
the principal point becomes the origin: 


#define MAX_LIGHTS 5 (— Macros.h) 
/*x This limit is generous, because some algorithms in the program run in 
quadratic time with the number of lights, and the program would run 

more slowly if it were pushed to these limits. +/ 


#define MAX_SYST (1+ MAX_LIGHTS) (— Macros.h) 
/* Screen system plus light systems. */ 

#define SCREEN_SYST 0 (— Macros.h) 

Vector Proj_center| MAX_SYST], Target, (—> Globals.h) 


/* Projection centers (i.e., the eye point and the light sources) and target 
point are global variables. We may get their coordinates from an input 
file. */ 

Vector *Coord_pool: (— Globals.h) 

/* The pool into which we write all the coordinates we want to have at our 
disposal. In Chapter 3.1, we will see how the pool is allocated. */ 


short Total_vertices; /*x Number of all points. */ (— Globals.h) 

short No-of_lights; (— Globals.h) 
/* This variable contains the exact number of lights. */ 

short Total_systems; (— Globals.h) 


/* The screen system plus all the light systems. Therefore, we let 
Total_systems = 1+ No.of lights; 
once we know the exact number of lights. «/ 


#-define Turn_vec(t, v) \ (— Macros.h) 
((t)[X] = -()[X], @[Y] = —-@)IY], ©1Z] = -(@)[Z)) 

| 

void translate_world_system(tar get) (— Proto.h) 
Vector target; 


{ /« begin translate_world_system() */ 


Vector t; /* The vector —target */ 
short syst; 


Turn_vec(t, target); 

translate_pool(T otal_systems, Proj_center, t); 

translate_pool(T otal_vertices, Coord_pool, t); 
} /* end translate_world_system() */ 
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In order to calculate the rotation matrices (Equation 4), we have to introduce 
a function that permits us to determine the “spherical coordinates” of a space 
point (radius, azimuth angle, and elevation angle): 


| 
void spherical_coords(d, azimuth, elevation, point) (— Proto.h) 


float «d; /+* Distance from the origin. */ 
double *azimuth, «elevation; 
Vector point; /* Given point in 3-space. */ 


{ /* begin spherical_coords() */ 
+d = Length(point); 
xazimuth = atan2(point|Y|, point|X] + EPS); 

/* This is the extended atan()-function; atan2(y, x) returns arctan (y/z) 
if x > 0, otherwise it returns arctan (y/z) + 7. */ 

xelevation = asin((double) point[Z] /(*d + EPS)): 

/* Do not forget to add EPS = 1e-7 to the dividends in atan2() and in 
asin() in order to avoid divisions by zero. The deviation from the cor- 
rect result is negligible. It is highly improbable that point[X] equals 
exactly —EPS (which would cause a division by zero), whereas 
the case point[X] = 0 is quite common. For a point on the z-axis 
(point|X] = point[Y] = 0) we now have the value +azimuth = 0. +/ 

} /* end spherical_coords() */ 


Now we need some additional global variables: 


double Dist|MAX_SYST], Azim|[MAX_SYST], Elev[ MAX_SYST], 
Twist; | (— Globals.h) 
/* Distance, azimuth angle, elevation of the projection centers in the different 
systems. The twist angle is only necessary for the screen system. */ 
Rot_matrix Rot/MAX_SYST], InvRot| MAX_SYST]; (— Globals .h) 
/* Rotation matrices and their inverse matrices. «/ 


This enables us to determine the rotation matrices (Equation 4) for all the sys- 
tems: 


[+S 
void fill_rot_matriz(r, angle, axis) (— Proto.h) 
Rot_matrix r; 
double angle; 
short azis; 
{ /* begin fill_rot_matriz() «/ 
register float s,c; /* For reasons of speed.+/ 
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s = sin(angle); c = cos(angle); 
switch(azis) { 


case X : 
r[0}[0] = 1; r[Olf1]= 0; r[0][2] = 0; 
rio] = 0; rfi]J= ¢ rfl][2] = s; 
r[2|[0] = 0; r[2)[1] = —s; r[2][2] = «; 
return; 
case Y : 
r[0|[o] = ¢; r[O][1]= 0; r[O][2] = —s; 
r(1][0] = 0; r[i][t]= 1; r[1][2]= 0, 
r[2|[0] = 3; r[2)1J= 0; r[2|[2]= 
return; 
case Z: 
r[0][o] = ¢; r[O]fi] = 3; r[0|[2] = 0; 
r(1][0] = —s; r[JJ= ¢ r[i][2]= 0; 
r[2][0] = 0; r[2][1] = 0; r[2][2] = 1; 
return; 
} I end fill_rot-matriz() */ 
#define PI 3.1415926 (— Macros.h) 
void calc_rot_matrix(syst) (— Proto.h) 


short syst; 


{ /* begin calc_rot_matriz() */ 
Rot_matrix z_alpha, x-_beta, z-gamma, zz; 
double alpha, beta, gamma; /* The Euler angles a, £, +. */ 
spherical.coords(&Dist|syst], 
&Azim|syst], &Elev|syst], Proj_center|syst]); 
alpha = Twist + (syst == SCREEN_SYST); 
beta = PI/2 — Elev[syst}; 
gamma = PI/2 + Azim[syst]; 
fill_rot-matriz(z-alpha, alpha, Z); 
fill_rot_matriz(x_beta, beta, X); 
fill_rot_matrix(z_gamma, gamma, Z); 
matriz_mult(zz, z-alpha, x-_beta); 
matriz_mult(InvRot|syst], zx, z-gamma); 
inverse_rot_matriz(Rot[syst], InvRot[syst]); 
}  /* end calc_rot_matriz() */ 


40 


Chapter 2. Projections 


The inverse matrix is calculated by means of this simple function: 


IT 
void inverse_rot_matriz(inv, mat) (— Proto.h) 
Rot_matrix inv, mat; 


{ /* begin inverse_rot_matriz() */ 
register short 1, j; 
for (i = 0; i < 3; i++) 
for (j = 0; j <3; j++) 
inv|i][j] = mat{y] [4]; 


} /* end inverse_rot_matriz() */ 


float Window_width, Window-height; (— Globals.h) 
/* Dimensions of the drawing window in pixels. */ 
float X.mid, Y_mid; (— Globals.h) 


/* These are the coordinates of the center of the window on the screen: 
X_mid = Window-width/2; Y mid = Window_height /2; 
+/ 
float Pizel_ratio; (— Globals.h) 
/* This is the system-dependent constant @ that corrects the distortion on 
the screen. (You can measure the distortion of a square.) If your coor- 
dinate system on the screen has its origin in the left upper corner, you 
will probably have Pizel_ratio ~ —1. 
*/ 
float Scale_factor; (— Globals.h) 
/* A stretch factor to fit the image of the scene into the drawing window. It 
is initialized by 
Scale_factor = Dist|0| * tan(Fovy/2); 
and may additionally be modified by an enlarge factor: 
*/ 


float Init( Enlarge, 1); (— Globals.h) 
/* To be able to zoom objects without changing the field-of-vision angle we 
let | | 


Scale_factor += Enlarge; 


*/ 


Here is at last the code of the function: 
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| 
void world.to_screen(screen, world) (— Proto.h) 


Vector screen; /* result */ 
Vector world; /* The point to be transformed. */ 


{ /* begin world_to_screen() */ 
register float lambda; 


vec_mult_matrix(screen, world, Rot|SCREEN_SYST)); 

lambda = Scale_f actor /(Dist(0] — screen|Z]); 

screen[X] = X_mid + lambda * screen[X]; 

screen[Y] = Y mid + lambda * Pizel_ratio * screen|Y]; 
} /* end world_to_screen() */ 


If we use a macro instead, we can speed up the process (an application of this 
macro will be given in Section 3.1.) 


#-define Rotate_and_project(scr, wld) \ (— Macros.h) 
(Vec_mult_matriz(*scr, *wld, *Rot), \ 
lambda = Scale_f actor /(Dist[0] — (*scr)[Z]), \ 
(xscr)[X] = X mid + lambda « (*scr)[X], \ 
(xscr)[Y] = Y_mid + Pizel_ratio * lambda * (*scr)[Y]) 








The inverse function screen_to_world() is needed only a few times. Therefore, 
we are satisfied with the code 


TI] 
void screen_to_world(world, screen) (— Proto.h) 
Vector world, screen; 


{ /« begin screen_to-world() */ 
register float lambda; 
Vector rotated; 


lambda = Scale_f actor /(Dist[0] — screen|[Z]); 
/* Undo projection */ 
rotated|X] = (screen[X] — X-mid)/lambda; 
rotated[Y] = (screen[Y] — Y-mid)/(Pizel_ratio « lambda); 
rotated|Z] = screen|Z]; 
vec_mult_matria(world, rotated, InvRot|SCREEN_SYST)); 


}  /* end screen_to_world() */ 
J [send screento-world)*/ 
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FIGURE 8. “World system” and “light system.” 


Let us now develop the equivalent functions (macros) for the light systems. This 
time the projection center is the n-th light source (given by Proj-center(n)). 
We can identify the origin (i.e., the former principal point) of the world system 
with a point on the “principal light ray.” The plane that contains the origin and 
that is normal to the principal light ray is our image plane (Figure 8). The only 
difference from the usual perspective is that we do not have to deal with twist 
angles, because it does not make any difference whether or not we rotate the 
“light bulb” about its axis. Instead of the function world_to_screen(), we write 
an equivalent function world_to_light(), which uses a macro 


#define Rotate_and_illuminate(shad, wld)\ | (— Macros.h) 
(Vec_mult_matriz(*shad, *wld, rot), 
lambda = Dist|n| / (Dist|n] — (*shad)|Z]), \ 
(*shad)[X] *= lambda, (*shad)[Y] «= lambda) 


7 
void world_to_light(shadow, world, n) (— Proto.h) 


Vector shadow, world; 
short n; /* The n-th light system. «/ 


{ /* begin worldtolight() +/ 
register float «rot = (float «) Rot([n); 
register Vector 
*shad = (Vector *) shadow, 
«wld = (Vector *) world; 
float lambda; /* Needed within the macro. */ 


Rotate_and_illuminate(shad, wld); 
} /* end world_tolight() */ | 
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The inverse function light_to_world() is very similar to the function screen-to- 
world(). The only difference is that we do not have to care about scalings, dis- 
tortions or translations to the center of the screen: 


aah " 
void light.to.world(world, shadow, n) (— Proto.h) 
Vector world, shadow; 
short n; /* The n-th light system */ 


{ /* begin light.to_world() */ 
register float lambda; 
Vector rotated; 
lambda = Dist{n]/(Dist|n] — shadow[Z]); /* Undo projection. +/ 
rotated|X| = shadow|X]|/lambda; 
rotated|Y | = shadow 7 /lambda; 





rotated|Z| = shadow|Z}; 
vec_mult_matriz(world, rotated, InvRot|n]); /* Rotate back. */ 
} /* end light.to_world() */ 


Sometimes we want to make a direct switch from the screen system to one of the 
light systems and vice versa. For the time being, a detour over the world system 
will help us to do so. 


Clipping Algorithms 

When the scene contains “forbidden points” and we try to display the scene, we 
will realize that the image of the scene is wrong (unless your system supports 
hardware-clipping). But even if there are no forbidden points, we want to have 
clipping routines for lines and polygons at our disposal, for example, when we 
store drawings to replay them in real time afterwards (Chapter 10) or when we 
want to draw “rubber bands” (Section 4.6) and our compiler does not support 
such a feature. 


The Two-Dimensional Clipping of a Line 


Cohen and Sutherland [HEAR86] developed a very fast method of detecting 
whether and how a line in the drawing plane has to be clipped. They divide the 
drawing plane into nine regions (Figure 9). The region a point belongs to can be 
detected by means of fast bitwise operations. The algorithm works exclusively 
with integers. 


If a point is inside the window, its region code is 0000. A point that is above and 
to the left of the window has a region code 0101, etc. When the region codes reg, 
and rege of the end points of a line segment are identical, it follows that the line 
is either completely inside the window (reg; = rego = 0) or completely outside 
the window. Otherwise the segment has to be clipped with the respective contour 
line of the window. 
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5 (0107) 4 (0100) 6 (0110) 
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7 (00017) 2 (0010) 
Min y 
9 (1001) 8 (1000) 10 (1010) 
Min xX Max x 
FIGURE 9. The nine regions of Cohen-Sutherland. 
short Min.z, Mazz, Min_y, Maz-y; 


#define LEFT Oz01 
#tdefine RIGHT 0:02 
#define ABOVE 0204 
#define BELOW 0208 
#define Region(reg, xz, y) {\ 
reg = 0;\ 
if (c¢ > Maz-_z)\ 
reg|= RIGHT; \ 
else if (x < Min_z)\ 
reg|= LEFT;\ 
if (y > Maz_y)\ 
reg| = ABOVE; \ 
else if (y < Min_y)\ 
reg|= BELOW; \ 


Bool clip2dtine(exists, p0, q0, p, q) 


Bool * exists; /* Is the line outside the clipping region? +*/ 
Vector p0, q0; /* The vertices of the clipped line. */ 


Vector p, q; /* The vertices of the line. */ 
{ /« begin clip2dtine() */ 


(— Globals.h 


(—> Macros. 
(— Macros. 
(—> Macros. 
(—> Macros. 
(— Macros.h 


bee 


pS’ 
me as 


(— Proto.h) 


register long 21 = p[X], yl-= p[Y], 22 = q[X], y2 = g[Y]; 


char regl, reg2; 
short temp, outside = 0; 
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x exists = TRUE; 

Region(reg1, x1, y1); 

Region(reg2, x2, y2); 

if (regl) ++outside; 

if (reg2) ++outside; 

if (!outside) return FALSE; 

while (regl | reg2) { 

if (regl & reg2) { /x Line outside window. */ 

xezists = FALSE; 
return TRUE; 


} 
if (regl == 0) { 
Swap(reg1, reg2); 
Swap (x1, x2); Swap(yl, y2); 


f (regl & RIGHT) { 
yl += ((y2 —yl) *(Minaz —21)) /(a2 — 21); 
v1 = Min-z; 

}else if (regl & LEFT) { 
yl += ((y2 —yl) *(Maz_x —21)) /(#2 — 21); 
zl = Maz-z; 

}else if (regl & ABOVE) { 
zl+= ((22 —al) *(Mazy —y1)) /(y2 —y1); 
yl = Maz.y; 

}else if (regl1 & BELOW) { 
zl+= ((22 —21) *(Miny — y1)) /(y2 — yl); 
yl = Min-y; 


} 
Region(reg1, x1, y1); 


} 
po[X] = 21; pO[Y] = yl; q0[X] = 22; g0[Y] = 
return TRUE; 

} /* end clip2d_line() */ 


The clipping region must be initialized. This is done by means of the function 
float Clip_vol[6); (—+ Globals.h) 


void zy_region(xmin, xmaz, ymin, ymaz) (— Proto.h) 


float zmin, xmaz, ymin, ymaz; 
{ /x begin ry_region() */ 


Maz.xz = Clip-_vol|0| = xmaz; 
Min.x = Clip-vol{1] = xmin; 
Maz_y = Clip_vol{2] = y maz; 
Miny = Clip-vol[3] = ymin; 


} /* end sy_region() */ 
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When the graphics window is opened, we write 
zy-region(0.0, Window_width, 0.0, Window-height); 


Now we introduce two pointers to a function 
Global Init.fptr(clip_line, clip2d_line); (— Proto.h) 


Global Init_fptr(draw_line, quick_line); (— Proto.h) 
/* The function quicktine() is explained in Section 4.2. «/ 


A function clip_and_plotine() looks like this: 


rr | 
void clip_and_plot_line(p, q) (— Proto.h) 
Vector p, g; 
{ /x begin clip_and_plot_line() */ 
Vector p0, gO; 


Bool exists; 
if (!clipline(&exists, p0, q0, p, g)) 
drawline(p, q); 
else if (exists) 
draw_line(p0, q0); 
} /* end clip_and_plot_line() */ 


When we have to do three-dimensional clipping or when we want to have other 
line styles (like XOR-lines) as well, we let draw-_line point to the respective 
function. This makes the code more readable and also faster because a lot of 
conditional branchings can be avoided. 


The Three-Dimensional Clipping of a Line 


When the scene contains forbidden points, we let the pointer point to the func- 
tion: 


clipline = clip3d_line; 


In order to develop the code for the function clip3d_line(), we extend the concept 
of the “regions” to three-space: 


float Min.z, Max-z; (— Globals.h) 
/* The z-values of the far and near clipping planes, given in the linear system 
(Transformation 21). */ 


#define MAX_POLY_SIZE 128 (— Macros.h) 
char Reg[MAX_POLY_SIZE; (— Globals.h) 
/* This space will also be used for the clipping of polygons. */ 


Section 2.5. Clipping Algorithms 47 


#define INFRONT 0210 | (— Macros.h) 

#define BEHIND 0220 (— Macros.h) 
char Clip_reg/6] = 

{ RIGHT, LEFT, ABOVE, BELOW, INFRONT, BEHIND}; 

/* Global in the current module. «/ 


#define Region3d(reg, x, y, z) {\ (— Macros.h) 
Region(reg, x, y); \ 
if (z > Mazz || z < —1)\ 
reg|= INFRONT; \ 
else if (z < Min_z)\ 
reg|= BEHIND;\ 


For three-dimensional clipping it is important that the z-values of the points of 
the line are transformed by means of the linear transformation (21). The z-values 
of regular points will then be in the interval —1 < z < oo. 


Before we do any clipping, we initialize the clipping planes: 


void z_region(far, near) (— Proto.h) 
float far, near; 


{ /* begin z_region() */ 
Maz.z = Clip_vol[4] = near; 
Min.z = Clip_vol|5|] = far; 
} /* end z_region() */ 


Good values for the initialization are 
z-region(—0.8, 4.0); 


Then all the points behind the far clipping plane Kk : Z = —0.8d/(1—0.8) = —4d 
and all the points in front of the near clipping plane k, : 7 = 4d/(1+4) =0.8d 
are outside the clipping volume (Formula (22)). The clipping with x, has to be 
done before the clipping with the drawing area: if one vertex of an edge is in 
the “forbidden halfspace,” its image point may well be inside the drawing area. 
After clipping with «,, however, the vertex is replaced by a point, the image of 
which can be outside the drawing area. 


The interpolation of the intersection point of the line with the clipping planes is 
done by means of the function 
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void intpol(r, a, b, 4) (— Proto.h) 
register float +7; /* The interpolated result. +/ 
register float +a, *b; /* The two end points. +/ 
register short i; /* Information about the order of z, y, z. */ 


{ /x begin intpol() */ 
static char c[6][3] = 
{X,Y,Z, X,Y,Z, Y,Z,X, Y,Z,X, Z,X,Y, Z,X,Y }; 
char cl, c2, c3; 
float ¢; 


cl = efi][X]; c2 = cfi][Y]; 8 = cli][Z]; 
t= (Clip_vol[i] — a[c1]) /(b[cl] -—alcl] + EPS); 
r{cl] = Clip_vol{i]; 
r(c2] = alc2] + t* (b[c2] — alc2)); 
r|c3 a[c3] + t* (b[c3] — alc3}); 
} /* end intpol() */ 


Finally, the code for the three-dimensional clipping looks like this: 


#-define Point_region(reg, p) {\ (— Macros.h) 


x = (p)[X];y = (w)[¥]; 2 = (p)[Z]; \ 
Region3d(reg, x,y, 2); \ 


#-define Copy-_vec(r, v)\ (— Macros.h) 
((r)[X] = (v)[X], (r[¥] = IY], [4] = ()[4)) | 

#define Copy_vec2(r, v)\ (—> Macros.h) 
((r)[X] = (v)[X], (r)[Y] = (~)[¥]) 

| 

Bool clip3d_line(exists, p0, q0, p, q) (— Proto.h) 


Bool * exists; /* Is the line outside the clipping volume? */ 
Vector p0, q0; /* The vertices of the clipped line. «/ 
Vector p, q; /* The vertices of the line. */ 


{ /* begin clip3d_line() */ 
register long x, y; 
register short 7; 
float z; 
Point-region(Reg[0], p); 
Point-region(Reg[{1], q); 
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if (!(Reg[0] | Reg[1])) /* No clipping. */ 
return FALSE; 
xexists = FALSE; 
for “(= 5;1>=0; i——) 
if (Reg[0] & Reg[1] & Clip_reg|i)) 
return TRUE; /* Line is outside of box. */ 
Copyvec(p0, p); Copy—vec(q0, q); 
for (t= 0;i< 6; i++) { 
if (Reg[0] & Reg[1] & Clip_reg|i)) 
return TRUE; /* Line is outside of box. */ 
if ((Reg[0| | Reg[1]) & Clip-regli)) { 
if (Reg|0] & Clip_reg[i|) /* First point is outside. */ 
intpol(p0, gO, p0, 4); 
else /* Second point is outside. «/ 
intpol(q0, pO, gO, 4); 
if (@ > 0) { 
Point_region(Reg(0], pO); 
Point_region(Reg[1], q0); 


} 
} /* end if (Reg(0}) +/ 
} /* end for (4) */ 
return -xezists = TRUE; 
} /* end clip3d_line() */ 


The Two-Dimensional Clipping of a Polygon 


Before we plot a two-dimensional polygon on the screen, we should clip it with 
the drawing window. This will save time when many of the polygons are outside 
the window. Clipping is also necessary when we store the polygons and replay 
them as fast as possible later on (Chapter 9). 


Figure 10 shows how the “reentrant polygon clipping” developed by Hodgman 
and Sutherland [SUTH74/1] works. The polygon is clipped at each side of the 
window so that it will take a maximum of four steps to get a polygon that is 
clipped correctly. The algorithm is comparatively fast. For reasons of speed, we 
introduce two temporary polygons Tmp1[ |] and Tmp2[ | where we store the 
provisional results. The code is written in such a manner as to make it work for 
both an array of Vector2s and Vectors. (We take advantage of the fact that 
both types are pointers to arrays of floats. ) 


float + Tmpl[MAX_POLY_SIZE), *T'mp2|MAX_POLY_SIZE|; (— Globals.h) 
short Init(Dim, 2); (— Globals.h) 


/* When the polygon is an array of three-dimensional Vectors, Dim must 
equal 3! «/ 
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FIGURE 10. The Hodgman-Sutherland algorithm for the clipping of a polygon in 


four steps. 
(a ee ee al 
Bool clip2d_polygon(n0, poly0, n, poly) (— Proto.h) 


short +* 70; /* Size of final polygon. «/ 

Vector poly0| |; /* Final polygon. */ 

short n; /* Number of vertices. */ 

float poly| |; /* Array of Vector2s or Vectors. «/ 


{ /* begin clip2d_polygon() */ 
static float additional|8 * sizeof(Vector)], «add; 
/* A maximum of eight intersection points plus a pointer. +/ 
register char «reg = Reg; 
char +*hi_reg = reg + n, code; 
register short z, y; 
register float «p = poly, *q; 
short edge, m, cl, c2; 
float **r; 
float *«ppoly; /* Pointer to Tmpl or Tmp?2. x/ 
float **pp, *«hi_pp; /* Pointers into ppoly| |. +/ 
float t; 
short cutoff = 0; 
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cut_off = 0; 
for (; reg < hi_reg; reg++, p += Dim) { 
xz = p[X], y = ply); 
Region(*reg, x, y); 
if (xreg!= 0) 
++cut_of f; 
} /* end for (reg) «/ 
«reg = Reg(0]; 
if (cutoff == 0) 
return FALSE; 
else if (cutoff ==n){/* Pol. might be outside of window. */ 
for (edge = 0; edge < 4; edge++) { 
code = Clip-_reg|edge]; 
for (reg = Reg; reg < hi_reg; reg++) 
if (!(*reg & code)) break; 
if (reg == hi-reg) { /* Polygon is outside of window. */ 
*nO = 0; 
return TRUE; 
} /* end if (reg) */ 
} /* end for (edge) */ 
} /* end if (cut_of f) */ 
p = poly; +n0 = n; 
/* Assign pointers to the vertices of the polygon. */ 
hipp = (pp = ppoly = Tmpl) + n; 
for (; pp < hi_pp; ppt++, p+= Dim) 
*pp = Pp; 
cl = X;c2 = Y; 
add = additional; 
for (edge = 0; edge < 4; edge++) { 
code = Clip_reg|edgel|; 
if (edge == 2) 
cl = Y, c2 = X; 
for (hi_reg = (reg = Reg) + *n0; reg < hi-reg; reg++) 
if (*reg & code) break; 
if (reg < hi-reg) { 
m = Clip_volledge]; 
hipp = (pp = ppoly) + *n0; 


thipp = *pp; 
r= ppoly = (ppoly == Tmpl ? Tmp2 : Tmpl); 
reg = Reg; 


while (pp < hi_pp) { 
p = *pptt; q = *pp; 
if (*reg++ & code) { 
if (!(*reg & code)) { 
* r++ add; 
add{cl] = m; 
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t= (m —plel]) /(qglel] — plet)); 
add{c2| = plc2] + (qlc2| — plc2]) * t; 


add += Dim; 
} /* end if (*reg) */ 
} else { 
*T+t+ = DP, 
if (*reg & code) { 
kr++ = ade 
add|cl] = 


t= (m ~ q{et]) /(ple1] —a|cl]); 
add[c2] = qlc2] + (plc2] —qlc2]) * ¢; 


if (Dim == 3 
add[Z] = q[Z] + (p[Z] —4[Z]) * ¢; 
add += Dim; 


} /* end if (xreg) */ 
} /* end if (#reg) */ 
} /* end while (pp) */ 
pp = ppoly; 
if (edge < 3) { /* Determine changed regions. */ 
for (reg = Reg; pp < r; reg++, ppt++) { 
Pp = *pp; 
2 = p[X]; y = plY]; 
Region(*reg, z, y); 
} /* end for (reg) */ 
«reg = Reg(0]; 
} /* end if (edge) */ 
*xn0 = r— ppoly; 
if (#n0 < 3) { 
*n0 = 0; 
return TRUE; 
}  /* end if (#n0) */ 
} /* end if (reg) */ 
} /* end for (edge) */ 
p = &poly0(0](0); 
hipp = (pp = ppoly) + *n0; 
if (Dim == 2) 
for (; pp < hi_pp; ppt+, p += Dim) 
Copy-vec2(p, *pp); 
else 
for (; pp < hi_pp; ppt++, p += Dim) 
Copy-_vec(p, *pp); 
return TRUE; 
} /* end clip2d_polygon() */ - 
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Again we introduce a pointer to a function 
Global Init_fptr(clip_polygon, clip2d_polygon); (—> Proto.h) 


A function clip_and_draw-_polygon() looks like this: 


Global Init_fptr(draw_polygon, fill_poly); (— Proto.h) 
/* The function fill_poly() is explained in Section 4.2. */ 

| 

void clip.and_draw_polygon(n, poly) (— Proto.h) 
short n; 


float poly| |; 


{ /* begin clip.and_draw-_polygon() +*/ 
static short n0; _ 
Vector poly0|MAX_POLY_SIZE); 
/* This is space reserved for the clipped polygon. */ 


if (!clippolygon(&n0, poly0, n, poly)) 
draw_polygon(n, poly); 
else if (n0 >= 3) 
draw-_polygon(n0, poly0); 
} /* end clip_and_draw-_polygon() */ 


When we want to do three-dimensional clipping, to draw the outline of the 
polygon or to use other fill styles (e.g., smooth shading, see Section 4.6), we 
let draw-polygon point to the respective function. This makes the code more 
readable and faster because a lot of conditional branchings can be avoided. 


The Three-Dimensional Clipping of a Polygon 


For three-dimensional clipping, it is again important that the coordinates of the 
vertices of the polygon have been transformed by means of the linear transfor- 
mation (21). Points in front of the observer then have z-values with —1 < z < 00, 
whereas points in the forbidden halfspace have z-values < —1. 


Of course, the routine clip3d_polygon() is similar to clip_polygon(). Only if 3d- 
clipping is really necessary, we let 
clip-polygon = clip3d-_polygon; 


For example, if we plot the faces of an object that is not to be clipped at all, it 
is a waste of time to do the 3d-clipping for each face. 
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| 
Bool clip3d_polygon(n0, poly0, n, poly) (— Proto.h) 
short *170; /* Size of final polygon. */ 
Vector poly0| |; /* Final polygon. */ 
short n; /* Number of vertices. */ 
float poly| |; /* Array of Vectors. */ 


{ /* begin clip3d_polygon() */ 
static float additional[12 * sizeof(Vector)|, «add; 
/* A maximum of 12 intersection points plus a pointer. */ 
register char *reg = Reg; 
char *hi_reg = reg + n, code; 
register short 2, y; 
float z; 
register float *p = poly, xq; 
short 72; 
float **r; 
float **ppoly; /* Points to [mp1 or Tmp2. */ 
float **pp, **hi_pp; /* Pointers into ppoly| |. */ 
short cutoff = 0; 


for (; reg < hi-reg; reg++, p+= Dim) { 
Point_region(*reg, p); 
if (*reg!= 0) 
++cut_of f; 
} /* end for (reg) */ 
«reg = Reg(0}; 
if (cut_off == 0) 
return FALSE; 
else if (cutoff == n) { /* Pol. might be outside of box. */ 
for (i= 0; i< 6; i++) { 
code = Clip-_reg|i]; 
for (reg = Reg; reg < hi_reg; reg++) 
if ('(*reg & code)) break; 
if (reg == hi-_reg) { /* Polygon is outside of box. */ 
*n0 = 0; 
return TRUE; 
} /* end if (reg) */ 
} /* end for (i) */ 
} /* end if (cut_of f) */ 
p = poly; *n0 = n; 
/* Assign pointers to the vertices of the polygon. */ 
hipp = (pp = ppoly = Tmpl) + n; 
for (; pp < hi_pp; ppt++, p+ = Dim) 
* pp = P, 
add = additional: 
for (¢ = 5; i>=0; i-—) { 
code = Clip-_reg|i|; 
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FIGURE 11. 3d-clipping can be done in world coordinates (left side) or it can be 
applied to the linearily transformed scene (right side). In the latter case the projection 
is parallel orthographic and the viewing frustum is a parallelepiped (“box”). 
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for (hi-reg = (reg = Reg) + *n0; reg < hi-reg; reg++) 
if (*reg & code) break; 
if (reg < hi-reg) { 
hi_pp = (pp = ppoly) + xn0; 
x hipp = *pp; 
r= ppoly = (ppoly == Tmpl? Tmp2 : Tmpl); 
reg = Reg; 
while (op. < hi_pp) { 
p = *ppt+t+; q = *pp; 
if (*reg++ & code) { 
if (!(*reg & code)) { 


*Tr++ = add; 
intpol(add, p, q, 4); 
add += Dim; 
}else { 

*Trt++ = 

if (#reg & ‘code) { 
r++ = add; 
intpol(add, q, p, 1); 
add+= Dim; 


} /« end if (*reg & code) +/ 
/* end if (*reg) */ 
} al on ind (pp) */ 


if a > peoy f /* Determine changed regions. +/ 
for (reg = Reg; pp < r; regt++, ppt++t) { 
Pp = *pp, 
Point-_region(*reg, p); 


*reg = Reg(0|; 
} /* end if (i. <8) */ 
*n0 = r— ppoly; 
if (#n0 < 3) { 
*n0 = 
, Jeend i TRUE, 
* end if (+*n0) * 
} /* end if (reg) «/ 
} /* end for (i) */ 
/* Now copy everything to poly0. * y 
p = x*poly0; 
hipp = (pp = ppoly) + «nO; 
for (; pp < hi_pp; pp++, p+= Dim) 
Copy-vec(p, *pp); 
return TRUE, 


} /* end clip3d_polygon() «/ 
FPF Ene NPE POYIOTN) Pe 


Figure 11 illustrates how 3d-clipping works: on the left side, the viewing frustum 
was used to clip the scene, and on the right side, the whole scene was transformed 
by means of the linear transformation T2). 
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How to Describe 
Three-Dimensional Objects 


One of the main problems of 3D-computer graphics is the description of geo- 
metrical objects. The most straightforward way is to give the computer a list of 
all the vertices, including a list that explains how to connect these vertices to 
faces or edges, respectively. Then the computer can apply a general hidden-line 
or hidden-surface algorithm. 


Things get more complicated when the objects are not only defined geometrically, 
but also endowed with certain physical properties like transparency, reflecting 
surfaces, patterns, etc. In such a case, it turns out to be convenient to use a 
readable pseudo-code stored in data files, which may then be interpreted by an 
“object preprocessor” (i.e., a program that converts the pseudo-code into the 
above-mentioned lists). 


The way in which the pseudo-code is produced is just a matter of taste. It may 
simply be done by a text editor (this is the way programmers are accustomed to 
producing it) or by another program, the “graphics object editor” , which is more 
sophisticated (this is the way non-programmers want to do it). In principle, the 
way from the idea for a graphical scene to the solution of the problem is always: 


idea Object editor, jseudo-code object preprocessor jj,¢, object processor, jy) 
age of the scene. 

In this chapter, we will explain how an “object preprocessor” is written. However, 
we will not go into the creation of the corresponding data files by means of a 


sophisticated graphics object editor (i.e., a screen on which you can create and 
manipulate objects with a mouse). 
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3.1 


Thus, it will be shown how data files like the following can be read and inter- 
preted. 


PYRAMID metallic gray convex hollow 


vertices 
200,120,-7120,7200,-1720,31-720~, 
204,121,-7121,7204~,-71721~,41-241 
edges 
12,23,34,45,56,é61, 
78 ,89,910, 1011, 1112 ,127 , 
17,28,39,4410,65 11,612, 7 10 
faces 
123456, 
1287,2398,34109 , 451110 , 
5 61211,61712 ,10i11127 


The first thing we have to think of is how to organize memory. Arrays of pointers 
are extremely useful if we want to stay within certain storage limits (they also 
accelerate the program). In principle, we can say that we want to store every 
piece of information only once and that if we need this information elsewhere, 
we just store the address at which we can find it. 


Data Pools 


In Section 2.3, we learned how to get the screen coordinates and the light coor- 
dinates of a point. We will now see that it is possible to “fill coordinate pools” 
(ie., memory allocation of the same type, in this case, arrays of Vectors) in 
quite an efficient manner. We will also see how we can apply the same principles 
to a variety of other arrays. 


For the sake of convenience, we write two short functions that make the allocation 
and reallocation of memory safe and easy. The fact that C does not explicitly 
check many things, such as range errors and memory allocation failings, makes 
programs faster but also more sensitive to software errors. Therefore, memory 
allocation in particular should be checked every time! 
FILE [nit(+ Output, stdout); (— Globals.h) 
/* This is the file into which we write our messages. The file pointer can be 
set to any other stream by 
Output = fopen(" <arbitrary file name>", "w"); 
+/ 
#define Print(str)\ (— Macros .h) 
fprint f (Output, str) 
Bool Init( Window-_opened, FALSE); (— Globals.h) 
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void safe.exit(message) (— Proto.h) 


{ 


char *message; 
/* begin safe_exit() */ 
Print(message); 
if (Window_opened) 
OL ee /* This will be explained in Section 4.2. */ 
exit(0L); 
/* end safe_exit() */ 


J frend safe-enit) ef 


|! 
char * mem.alloc(n, size, name) (— Proto.h) 


} 


long n; /+ Number of elements of the array. */ 
short size; /* Size of each element in bytes. */ 
char *name; /* Name of variable (array) we want to allocate. */ 


/* begin mem_alloc() */ 
char «address; 
address = (char *) malloc(n * size); 
/* This is the (system-dependent) UNIX function 
char *malloc(long); 
for the allocation of memory. It returns NULL when the necessary 
memory is not available. If you use a different compiler, the function 
may have a slightly different name! 


+/ 
if jafaress != NULL) return address; 
else 
Print("Cannot allocate "); 
safe_exit(name); 
/* end if */ 
/* end mem.alloc() */ 


i ] 
char * mem_realloc(orig.address, n, size, name) (— Proto.h) 


} 


char *+orig_address; /* The original address of memory. */ 

long n; /* Number of elements of the array. */ 

short size; /* Size of each element in bytes. */ : 

char «name; /* Name of variable (array) we want to allocate. */ 


/* begin mem-_realloc() */ 
char *new_address; 


new-_address = (char *) realloc(orig_address, n * size); 
__ /* System-dependent!!! See mem_alloc(). */ 
if (new-address |= NULL) return new-address; 
else 
Print( "cannot reallocate "); 
safe_exit(name); 
} /* end if «/ 
/* end mem-realloc() */ 
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In our object preprocessor, there are a few arrays, the size of which is unknown 
before allocation: Coord_pool, Edge-pool, Face_pool, Object_pool. Before any 
data are read, we allocate a reasonable amount of storage to the world coor- 
dinates of all points, edges, faces and objects: 


#-define MAX_POINTS 4000 (+ Macros.h) 
/* The number 4000 is just a suggestion. If you have enough RAM, take 
a higher number. Since a vector consists of three floats (sizeof(float) 
= 4 bytes), 4000 vectors need 48 Kbytes of RAM-memory. The pool is 
reallocated as soon as we know the precise number of points so that we 

do not waste any memory! */ 


#define MAX_EDGES 6000 (— Macros.h) 
/* Takes 48 Kbytes, because for each edge we need two pointers to vectors 
of the size of 4 bytes each. */ 


#-define MAX_FACES 2500 (— Macros.h) 
/* The definition of the structure Face is given in Section 3.2. Because 
sizeof(Face) ~ 40, 2500 faces need 100 Kbytes. */ 


#define MAX_UBYTE (1L <« (8*sizeof(Ubyte))) (—> Macros.h) 
/* Thisis 1 << 8=2550r1l < 16= 65535.1«/ : 
typedef unsigned char Ubyte; | (— Types .h) 


/* 0... MAX_UBYTE. */ 


/* The only reason why we introduce the type Ubyte is because it helps to save 
space (we will use more-dimensional arrays consisting of elements of this 
type). If you have a computer with enough RAM-memory, you can define 
Ubyte as a short. Then you will have no restrictions as to the number of 
objects (polyhedra) you want to display. */ 


#define MAX.POL (MAX_UBYTE — 1) (— Macros.h) 
/* Maximum number of polyhedra. The definition of the structure Polyhe- 
dron is given in Section 3.2. */ 
Vector +Screen_pool; (— Globalis .h) 
/* The pool into which we write all the screen coordinates. */ 
Vector *Light_pool[ MAX_SYST}; (— Globals .h) 


/* The pools into which we write all the coordinates in the different light 
systems. Since we may have several light sources, it is an array of pointers. 


*/ 


‘The C preprocessor will replace the constant by the result of the shift oper- 
ation every time it appears in the code. 
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Vector *Cur_coord;? (— Globals.h) 


/* This is a pointer that indicates where we are in Coord_pool while we 
read from the data file. It is initialized when we allocate the coordinate 
pool. Whenever we store the world coordinates of a point of the scene 
(including points like barycenters, etc.), we increase Cur_coord by one. 


*/ 





FIGURE 1. Edge_pool is an array of pointers into Coord_pool. 


Vector ** Edge_pool, ** Cur_edge; (— Globals.h) 


/* Edge pool plus a pointer into the pool. Cur_edge is initialized when we 
allocate the pool, and it is increased by two every time we store the 
two vertices of an edge. Thus, the pointers to the vertices of all edges 
are stored one after the other in an Edge_pool. The n-th edge has the 
vertices *dge_pool|2 « n|, *Edge-pool|[2 * n + 1] (Figure 1). */ 


Face «Face_pool, + Cur_face; (— Globals.h) 


/* Face pool plus a pointer into the pool. Cur_face is initialized when we 
allocate the pool, and it is increased by one every time we store a face. 


*/ 
Polyhedron *Object_pool, *Cur_object; (— Globals.h) 


/* Object pool plus a pointer into the pool. Cur_object is initialized when 
we allocate the pool, and it is increased by one every time we store an 
object. */ 


2Pointers into pools will often begin with the prefix “cur” (which stands for 
“current” or, if you want, for “cursor” ). This indicates that they will usually run 
through loops. The upper limit of such a loop will frequently also be a pointer 
of the same type, the name of which will usually have the prefix “hz.” 
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Coord_pool = Cur-coord = (Vector *)? 

mem_allociMAX_POINTS, sizeof(Vector), "Coord_pool"); 
Edge-_pool = Cur.edge = (Vector +) 

mem_alloc(MAX_EDGES, 2 * sizeof(Vector *), "Edge-pool"); 
Face pool = Cur_face = (Face *) 

mem-alloc( MAX_FACES, sizeof(Face), "Face_pool"); 


Object_pool = Cur_object = (Polyhedron *) 
mem-alloc(MAX_POL, sizeof(Polyhedron), "0Object_pool"); 


For more convenience, we can abbreviate the lines 


array = (type *) mem-alloc(size, sizeof(type), string); 


ptr_array = (type **) mem_alloc(size, sizeof(type *), string); 


by means of the macros: 


#¢-define Alloc_array(type, array, n, string)\ (— Macros.h) 
array = (type *) mem_alloc((long) n, sizeof(type), string) 
#¢-define Alloc_ptr_array(type, ptr_array, n, string)\ (— Macros.h) 


ptr_array = (type **) mem-alloc((long) n, sizeof(type *), string) 
The allocations of Coord_pool and Edge-pool can then be written like this: 


Alloc_array(Vector, Coord_pool, MAX-POINTS, "Coord_pool"); 
Alloc_ptr_array(Vector, Edge_pool, 2 * MAX_EDGES, "Edge-pool"); 


After having stored all the information, we make use of the scaling nature of 
pointers to calculate the actual sizes of the pools: 


short Total_edges, Total_faces, Total_objects; (— Globals.h) 
/* Total_vertices was defined in Chapter 2. */ 

Total _vertices = Cur.coord — Coord_pool: 

Total_edges = Cur_egde — E'dge_pool:; 

Total_faces = Cur_face — Face_pool; 

Total_objects = Cur_object — Object_pool; 


Now we can reallocate the pools: 


#-define Realloc.array(type, array, n, string)\ (— Macros.h) 
array = (type *) mem_realloc(array, n, sizeof(type), string) 
#-define Realloc_ptr_array(type, p-arr, n, string) \ _ (— Macros.h) 


p-arr = (type **) mem-realloc(p_arr, n, sizeof(type *), string) 


“If you do not cast the function mem_alloc(), you will at least get a warning 
message from the compiler. 
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Realloc_array(Vector, Coord_pool, Total_vertices, "coords"); 
Realloc_ptr_array(Vector, Edge_pool, Total.edges, "edges"); 
etc. 


Furthermore, we can allocate the exact amount of storage for the other coordinate 
pools: 


Alloc_array(Vector, Screen_pool, Total_.systems * Total_vertices, 
"Screen and light pools"); 
for (i=0; i < noofJights; i++) 
Light-pool|i] = Screen_pool + i * Total_vertices; 


/* We identify the zeroth light pool with the screen pool. This allows fast 
switches between the screen system and the light systems as we will see 
very soon. +/ 


The n-th point of the scene is given by *(Coord_pool + n) in the world system, 
by *(Screen_pool + n) in the screen system and by *(Light_pool[k] + n) in the 
k-th light system. 


Provided that the n-th vector in the screen pool really contains the screen coor- 
dinates of the n-th vector of the coordinate pool, we can easily switch between 
the coordinate systems by means of macros: 


#-define Screen_coords(world) \ (— Macros.h) 
(Screen_pool + (world — Coord_pool)) 
#-define Light_coords(n, world)\ (— Macros.h) 


(Light_pool{n] + (world — Coord_pool)) 


(The variable world must be a pointer to a Vector.) Here is an example of the 
usefulness of these macros: let p and q be pointers to the world coordinates of 
two vertices. Then we can draw a line that connects the images of these vertices 
simply by writing 


plot_line(*Screen_coords(p), *Screen_coords(q)); 

(The function plot_line() is explained in Section 4.6.) 

Since we have identified the zeroth light system with the screen system, we can 

switch directly between these systems by means of the macro 

#-define Switch_syst(old_syst, new-_syst, v)\ (— Macros.h) 
(Light_pool|new_syst] + (v — Light_pool[old_syst})) 

In order to get the corresponding screen coordinates of a Vector v in the n-th 

light system, we now write 

v = Switch_syst(n, SCREEN_SYST, v); 


The following function shows how we can “fill the screen pool” very efficiently 
in the desired manner: 
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void fill_screen_pool() (— Proto.h) 


{ /x« begin fill_screen_pool() */ 
register Vector 
xworld = Coord_pool, /* Pointer into coordinate pool. */ 
«screen = Screen_pool, /* Pointer into screen pool. */ 
+hi_world = world + Total_vertices; 
register float lambda; /* Used within macro. */ 
draw_line = quick_line; 
/* As long as no point is in the “forbidden halfspace,” 
we do not have to think about clipping. +/ 
for (; world < hi_world; world++, screen++) { 
Rotate.and_project(screen, world); 
if ((*screen)[Z| >= Dist|SCREEN_SYST}) 
draw_line = clip3d_line; 


} 
} /x end fill_screen_pool() */ 


Note that the function does not call any other functions and that it works almost 
exclusively with register variables. 


The “n-th lightpool” can be filled as quickly as the screen pool: 


| 
void fill_light_pool(n) (—> Proto.h) 
short n; /* Index of light system. +/ 


{ /« begin fill tight-pool() */ 
register Vector 
«world = Coord_pool, /* Pointer into coordinate pool. */ 
«shadow = (Vector *) Light_pool(n], /* Ptr into light pool. */ 
#hi_world = world + Total_vertices; 


register float +rot = (float *) Rot[n], lambda; /* Used within macro. */ 
for (; world < hi_world; world++) 
Rotate_and_illuminate(shadow, world); 
} /* end filllightpool() */ 


Another example of the scaling nature of pointers may be the following task: you 
want to get a list of the names of all the objects. 
Polyhedron * 0bj = Object_pool, *hi_obj = obj + Total_objects; 
while (0bj < hi_obj) 
forint f (Output, "%s\n", 0bj3++-—>name); 
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Several other pools like the “color pool,” the “normal pool,” the “mirror pool,” 
the “contour pool” and so forth will be declared later on. 





Sometimes we have to allocate higher-dimensional arrays dynamically. For ex- 
ample, let us assume that we want to allocate the two-dimensional array short 
z{n|[m|. The array has nm elements of the type short. The writing x{i][j] is 
turned into *(x[z] + 7) by the compiler. Thus, the computer needs information 
about the n pointers z|i]. Therefore, the allocation of the array has to be done 
in three steps: 


/* First allocate the n pointers. */ 
xz =(short +**) mem-alloc(n, sizeof(short *), "x"); 
/* Now allocate space for the entire array. +/ 
z|0] = (short *) mem_alloc(n, mx sizeof(short), "x(0]"); 
/* Finally, initialize the rest of the pointers. */ 
for (i=1; i<n; i++) 
zi] = 2[t — 1] +m; 


It is fairly complicated to rewrite these lines for every new allocation and there 
is always the danger of memory errors. This problem cannot be solved by a 
function, because we have to distinguish between different types of variables, if 
the pointers are to be cast correctly. In fact, this is exactly the case where a 
C macro comes in handy. (Note the use of commas and semicolons — we cannot 
use a comma before a loop.) 


#define Alloc_2d_array(type, array, n, m)\ 
array = (type **) mem-alloc((long) n, sizeof(type +), "pointers"),\ 
array|0| = (type *) mem-alloc((long) n, m * sizeof(type), "2d-array");\ 
for (i= 1; i <n; i++)\ 
array|i| = array[i — 1] +m; 


The macro can be very tricky if it is written like this. For example, if we write 
for (j =0; 7 < jmaz; j++) 
Alloc.2d_array(...); 


we will not get a syntax error, but only the first statement of the macro will be 
in the loop! Especially when we deal with memory functions, this is an error that 
cannot be traced easily and that will cause the program to crash. For this reason, 
we rewrite the macro by taking advantage of the fact that, in C, we can write 
whole sections of the code as macros, if we only write the code inside braces: 


#-define Alloc_2d_array(type, array, n, m) {\ (— Macros .h) 
array = (type **) mem-alloc(n, sizeof(type *), "pointers");\ 
array|0] = (type *) mem-_alloc(n, m * sizeof(type), "2d-array");\ 
for (i= 1; i <n; i++)\ 
array|i] = array[i — 1] +m;\ 
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To free the array, we introduce the macro 


#define Free_2d_array(array) \ (— Macros .h) 
(Free.array((char *) array[0]), Free_array((char *) array)) 


To allocate and to free the array short x[n|[m], we write 


Alloc_2d_array(short , z, n, m); 
Free_2d_array(z2); 


The ‘Polyhedron’ and ‘Face’ Structures 


Before we start developing an “object preprocessor,” let us think of what a 
structure has to look like if it is to store all the necessary information about an 
“object.” As a matter of fact, in this book, an object will always be a (closed 
or not closed) polyhedron that consists of a certain number of polygons. Thus, 
we do not define every polygon as an object in its own right, as some compara- 
ble algorithms do. Quite on the contrary, we will try to keep together as many 
polygons as possible within units. 


Let us first define a structure “Face” that contains all the necessary information 
about the facets of the polyhedra: 


typedef struct { /* Face */ 
short no_of_vertices; /* Number of vertices. */ 
Vector vertices; 
/* An array of pointers to vectors. The n-th point is evaluated by 
*(vertices[n]) = «*(vertices +n). */ 

Ubyte color; /* Index of corresponding color palette. «/ 
Ubyte physical_property; 

/* The polyhedron can be metallic, shiny, transparent, etc. «/ 
Vector normal; /* The normalized normal vector. +/ 
float cnst; /* The constant of the plane of the polygon. «/ 
float incidence; 

/* Average angle of incidence of the facet with the light rays. */ 
Ubyte no_of _neighbor_faces; struct Face *neighbor_faces;* 

/* Array of pointers to neighbor faces. The n-th neighbor face is 
*((Face «) neighbor_faces[n]) */ 

Vector «barycenter; 

/* “Center” of face (i.e., the arithmetic mean of the coordinates of the 
vertices). Useful for the calculation of the average depth of the facet 
or the average angle of incidence of the facet, etc. */ 

} Face; (— Types .h) 


“We would prefer to simply write Face «neighbor_faces.- However, this is not 
possible, because the compiler does not yet know about the structure Face. 
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Here is an example of how a structure or record Polyhedron might look like: 


typedef struct { /+ Polyhedron */ 
char *name; 

/* Each object gets a name in the data file. When we write the data file, 
we call the objects by readable names. When the object preprocessor 
reads the file, it will thus be able to give readable information. +/ 

Ubyte indez; 

/* In the program, the object is not called by a name but by an index. 
Because we keep many faces together, we limit the number of objects 
to MAX_UBYTE = 255 (usually this is a very complicated scene with 
thousands of faces). The main reason for this is that we work with 
priority lists, where the priority of each object in comparison with 
all the other objects is stored. To work with more than 255 objects 
(see definition of Ubyte) should be left to really fast computers. */ 

Ubyte color_indez; 

/* Index of color palette.° The different shades of this special palette 
will be calculated during the program. Because of a minimum size 
for each color palette (necessary for smooth shading) and because of 
the limited number of colors that can be displayed simultaneousely on 
the screen, we will be able to create only a small number of palettes 
(e.g., 8 “parent palettes” plus 16 “subpalettes” in the case of 256 
displayable colors and a palette size of 32). */ 

Ubyte geom_property; 

/* The polyhedron can be convex, hollow with convex outline, concave, 
etc. */ 

Ubyte physical_property; 

/* The polyhedron can be reflecting, metallic, mat, transparent, etc. */ 

short type; 

/* We distinguish between several kinds of polyhedra: polyhedra of re- 
volution, polyhedra of translation, general polyhedra, mathematical 
surfaces, etc. */ 

short no-_of -vertices; 
/* Number of vertices on the polyhedron. +*/ 
Vector *vertices; 

/* This is the pointer to the coordinate pool. From vertices to 
(vertices + no_of vertices), the coordinates of all the points on 
the polyhedron are stored. The n-th point, for example, has the y- 
coordinate vertices[n][Y] or (*(vertices + n))[Y]. */ 

Vector *hi_coord; 


5A “palette” in our sense is a chart of different shades of one and the same 
color. Therefore, the constant PALETTE_SIZE means the number of the different 
shades of one single color. 
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/* This pointer into Coord_pool is similar to the previous one. However, 
we will not let this variable point to the coordinates of the last ver- 
tex of the object, but a little bit further. After the coordinates of 
the vertices we store several other points of the object, the screen 
coordinates or light coordinates of which we want to calculate. */ 

short no-of-edges; 

/* Number of edges. All the edges are stored in an “edge pool,” which 
allows us to quickly draw wireframes or to remove hidden lines. */ 

Vector **edges; 

/* This is the pointer to where the edges of the object are stored. The 
“sk” indicates that, in fact, it is an array of pointers. The storage 
works like this: the n-th edge has two end points, the pointers to 
which are stored at edges[2 * n| and edges([2 + n + 1]. Therefore, the 
points themselves are stored at *(edges[2 * n]) = **(edges + 2 * n) 
and +(edges[2 *n + 1]) = #*(edges+2*n+1). */ 

short no-_of_faces; 

/* The number of faces on the polyhedron. Complicated polyhedra like 

function graphs may have several thousands of them. +/ 
Face «faces; | 

/* This is the pointer to the beginning of the “face pool,” where all 
the faces are stored. The n-th face of the polyhedron is stored at 
faces[n]. */ 

Vector *barycenter; 

/* The barycenter is a point, the coordinates of which are the arithmetic 
mean of the coordinates of all the vertices. In the case of convex 
polyhedra, this point is always inside the object. By means of the 
barycenter, we can orient the normals of the faces. Usually we can 
do a rough sorting of the priority list as well. In most cases, however, 
additional priority tests have to be applied. The memory for the point 
does not have to be allocated (the variable points into Coord_pool). 

*/ 

} Polyhedron; /* end of struct */ (— Types.h) 


The structure looks rather complicated by now. In the following chapters, how- 
ever, we will still add some more structure members. 


General Convex Objects 


A planar polygon is conver when it lies entirely on one side of each line that is 
determined by an edge. This occurs when no interior angle is greater than x. If 
an interior angle is greater than 7, the polygon is concave. All the straight lines 
that cross the interior of a convex polygon cut two of its sides. Convex polygons 
are extremely important for many algorithms in computer geometry. 
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Our definition of convexity can be extended to 3-space: a polyhedron is convex 
when it lies entirely on one side of each plane that is determined by a face. 
The most common examples for such polyhedra are prisms and pyramids with 
convex base polygons. Special cases of these polyhedra, such as orthogonal par- 
allelepipeds or regular prisms and pyramids, fulfill additional conditions and will 
be treated separately. 





ry 


Fal 


FIGURE 2. A simple object with convex outline. 


If we want to describe a simple object like the one in Figure 2, we have to give 
the computer the following facts: 


1. The object has 12 vertices, the coordinates of which are: 
P,(2,0,0), P2(1, 2,0), P3(—1, 2,0), 
P,(—2,0,0), Ps(—1, —2,0), P(1, —2, 0), 
P,(2,0, 4), Pg(1, 2,1), Po(—1, 2,1), 
Pyo(—2,0, 4), Prr(—1, —2, 1), Pro(1, —2, 1) 
2. We want to draw the following 19 edges of the polyhedron: 
Pi P2, P2P3, P3P4, PaPs, PsPe, PePi, 
P7Pg, PgP9, PoPio, PioPu, PiiPi2, Pi2Pr, 
P,P7, P2Ps, P3Po, PaPio, P5Pii, PePia, 
P7P1o 
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In this case it is not absolutely necessary to give the computer the edge list. 
When each edge is defined as the side of a face, the computer can take them 
from the face list. 


3. The polyhedron has 8 faces: 
(P, P2P3P,PsPs), (P:P2P3P7), (PoP3P9Ps3), (P3PsPioPo), 
(PsPsPiiPio), (PsPePi2Pii1), (PePiP7Pi2), (ProPi1Pi2P7) 


All this can be achieved by the data file in the introduction of this chapter. 
The first line of the data file contains some keywords that inform the object 
preprocessor about the kind of object we deal with, its color and its physical and 
geometrical properties. 


Of course, it is tedious to count all the vertices, edges and faces. However, if we 
do not do that it will be more difficult to write a function that interprets the 
last three lines correctly. 


Let us first write a function by means of which we can safely open a file: 


| 
FILE * safe_open( filename, mode) (—> Proto.h) 
char «filename, *mode; | 
{ /* begin safe_open() */ 
FILE + fp; 
if ((fp = fopen( filename, mode)) == NULL) { 
Print("Cannot open file "); 
safe_exit (file name); 
} /* end if (!fp) */ 
return fp; 
} /* end safe_open() */ 


Now we introduce some new global variables: 


FILE +*Input; (— Globals.h) 
/* This is the file from which we read the data. It is initialized by 
Input = safe_open(" <arbitrary file name>", "r"); */ 


char Comment(260}; (—> Globals.h) 
/* A string we read from the input file. +/ 

#define Fread_vec(v)\ — Macros.h) 
fscanf(Input, "*f%f%f", &((v)[X]), &((v)[¥]), &((v)[Z])) 

#-define Fread_str(string)\ (— Macros.h) 


fscanf (Input, "%s", string) 


{ 


} 


{ 
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void check_keyword(keywd, obj) (— Proto.h) 
char +keywd; 


/* We check whether the word we read is this word. +/ 
Polyhedron +*o0bj; /* The object we read. «/ 


/* begin check_keyword() */ 

Fread_str(Comment); 

if (stremp(Comment, keywd)) { 
fprintf(Output, "Error while reading object %s:\n", 0bj >name); 
fprintf(Output, "keyword '%s’ \n", keywd); 
safe_exit("expected"): 

} /* end if (stremp) */ 

/* end check_keyword() */ 


a 
void read_general_convex_polyhedron(obj) (— Proto.h) 


Polyhedron *obj; /* The object we want to read now. */ 


/* begin read_general_convex_polyhedron() */ 
register short * indices; 
/* This large array will be allocated and freed within the function. For 
the time being, it stores the indices of the vertices of all the faces of 
the polyhedron. */ 


register short ¥*cur_indez, *hi_indezx; 
Vector «world; 

Face + hi_face; 

Bool edgelist_is_given; 


/* Now we read the vertices. When there is no comma after three coordi- 
nates, the vertex list is complete. */ 


Fread_str(Comment); 
check_keyword("vertices", obj); 


obj vertices = Cur-_coord; 
/* Read coordinates of vertices until there is no commma left. * / 
do { 


Fread_vec(*Cur_coord); Cur-coord++; 
/* Do not write Fread_vec(*Cur_coord++); (macro!) */ 
Fread_str(Comment); 
} while (Comment[0] == ’,’); 
obj >no-.of vertices = Cur_coord — obj +> vertices; 
/* Read edges. */ 
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if (!stremp(Comment, “edges")) { 
edgelistis.given = TRUE; 
obj —->edges = Cur_edge; obj ->no-of-edges = 0Q; 
/* Read indices of vertices until there is no comma left. «/ 
do { 
obj >no-of edges++; 
* Curedge++ = obj—>vertices + read_pos_int() — 1; 
+ Curedge++ = obj—>vertices + read_pos.int() — 1; 
Fread_str(Comment); 
} while (Comment|0] == ’,’); 
} else edgelistis_given = FALSE; 


/* Read faces. */ 


check_keyword("faces", 0b7); 
Alloc_array(short, indices, 5000, "indices"); 
hiindex = (cur-inder = indices) + 5000; 
obj +> no_of faces = 0; 
while (curindex < hi-indez) { 
Fread_str( Comment); 
* cur_index = atoi(Comment) — 1, 
if (*curinder == —1) { 
obj >no-of -faces++; 
if (Comment(0|!= ’,’ || feof(Input)) break; 
} /* end if (*cur_index) x 
cur_inder++; 
} /* end while (cur_index) */ 
/* Now copy everything to obj > faces. */ 
hi-face = (obj—>faces = Cur_face) + obj >no-of-_faces; 
hiindex = indices; 
for (; Cur.face < hi_face; Cur_face++) { 
cur_inder = hi_indez; 
/* Count vertices. */ 
while (*hiindex >= 0) hi_index++; 
Cur_face—>no_of vertices = hi_index — cur_indez; 
/* Allocate array of pointers to vertices. */ 
world = Alloc_ptr_array(Vector, 
Cur_face-—>vertices, Cur_face—>no-_of _vertices, "v"); 
for (; cur-inder < hiindez; curinder++, world++) 
* world = obj—>vertices + (*curindex .— 1); 
hiindez++; /* Forget index -1. */ 
} /* end for (Cur_face) */ 
Free_array(indices, "indices"); 
if (!edgelist_is_given) 
get_edges_from_facelist(obj); 
} /* end read_general_convex_polyhedron() */ 
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The subroutine calls a function read_pos_int(), which is quite useful for the 
detection of errors in the data file: 


int read_pos_int() (— Proto.h) 


int 7; 

fecanf (Input, "4a", &n); 

if(n >= 0 && n < 32000) 
return 17; 

else { 
ftoa®((double ) n, Comment, 0, 1); 
Print("Positive integer expected instead of "); 
sa fe_exit( Comment); 

} /* end if (n) */ 

} /* end read_pos.int() */ 


When the edge list is not given, the computer looks for all the edges that any 
two faces have in common: 


CT 
void get_edges_from-facelist(obj) (— Proto.h) 

Polyhedron + obj; 
{ /« begin get_edges_from_facelist() */ 

Face * f1, *f2, *hi_f = obj > faces + obj->no-of _faces; 

Vector * pl, *p2; 

short il, i2; /* In this case only dummies. */ 

obj edges = Cur-edge; 0bj->no_of-edges = 0; 

for (f1 = obj—>faces; fl < hi-f —1; f1+4) 

for (f2 = fl +1; f2 < hi_f; f2++) 
if (common.edge(&pl, &p2, &i1, &i2, fl, f2)) 
* Cur.edge++ = pl, *Cur_edge++ = p2; 

obj >no_of edges = (Cur-edge — obj edges) / 2; 

} /«* end get_edges_from_facelist() */ 


The function common-edge() is useful for several purposes, e.g., for the detection 
of contour polygons: | 


®In TURBO C use the function ltoa() instead. 
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I 
Bool common-edge(a, 6, idx_a, idr_b, f1, f2) (— Proto.h) 
Vector xa, **b;  /* Vertices of the edge. */ 
short *idz_a, *idx_b; /* Indices of a, b in the fl-list. */ 
Face «fl, *f2; /* The two faces. */ 


{ /x begin common_edge() */ 
register Vector **curl, **cur2, hil, **hi2, **lol, **lo2; 


hil (lol = fl—vertices)+ f1l—>no_of vertices; 
hi2 (lol = f2—>vertices)+ f2—>no-_of -vertices; 
*a = NULL; 
for (curl = lol; curl < hil; curl++) 

for (cur2 = lo2; cur2 < hi2; cur2++) 


if (xcurl == +*cur2) { 
if (ta == NULL) { 
*a = xcurl; xidr.a = curl — lol; break; 
}else { 


*b= «curl; *idz.b = curl —lol; return TRUE; 
} /* end if (*a) */ 
} /* end if (*cur1) */ 
return FALSE; 
}  /* end common_edge() */ 


3.4 Surfaces of Revolution 


Surfaces of revolution — or more accurately, polyhedra that approximate surfaces 
of revolution — are probably the best-known geometrical primitives. Figure 3 
shows what we call a “surface of revolution” in this book. The polyhedron is 
determined by a “meridian polygon” and by the “order,” i.e., by the number of 
the sides of the regular section polygons. By default, the “rotation angle” 9 equals 
27. The process in which such polyhedra are generated is called “rotational 
sweeping” [THAL87]. 


When s is the “size” of the meridian polygon and r the order of the polyhedron, 
the polyhedron will normally have r s vertices, r(2s—1) edges and r(s—1)+2 faces 
(quadrilaterals). However, the number of vertices, edges and faces will decrease 
when a meridian point is on the rotation axis. (By default, the rotation axis is 
identical to the z-axis.) The meridian polygon should lie on a “meridian plane,” 
which goes through the axis. (Otherwise, we would have to split the quadrilateral 
patches into triangles. ) 


In this section, we will see how the second line in the data file 


CONE green revolution solid 
meridian 400 , O 0 7 order 30 
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can be read and interpreted correctly. We will store a face list and an edge list 
for the respective convex polyhedron (Figure 3a). In addition to that, we will 
also work with data lines like 


CYLINDER orange revolution hollow +bottom 
meridian 2.5 0 -5 , 2.5 0 5 order 40 


which describe hollow surfaces of revolution — preferably with convex outlines 
(Figure 3b) — or 


ROTSWEEP lightcyan revolution solid rot_angle 180 
meridian 20-5 , 30 -2,303 ,00 5 order 20 


which describe specific parts of such surfaces (Figure 3c). 





FIGURE 3. Approximations to a surface of revolution. The polyhedra can be a) solid, 
b) hollow, c) cut off. 


For fast hidden-line (hidden-surface) removal (Chapters 5 and 7) and especially 
for the fast generation of shadows (Chapter 6), it is often a good idea to split 
the primitives into conver parts (Figure 4). 


When we read the coordinates of a point on the meridian from the data file, a 
function 


Bool is_on_azis(p) (— Proto.h) 
Vector *p; 


{ /x begin is_on_azis() «/ 
return ((*p)[X]| == O && (*p)[Y] == 0) ? TRUE : FALSE; 
} /* end is_on_axis() */ 
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FIGURE 4. How to split a non-convex surface of revolution in order to speed up the 
rendering algorithms. 


can decide whether this point is on the rotation axis (= z—axis). Another func- 
tion corr_vertez() helps to determine the pointer to a vertex of the polyhedron, 
when the order and the index of the corresponding point on the meridian are 


given: 
De ee 
Vector * corr_vertex(index, order) (— Proto.h) 


short indez, order; 


{ /* begin corr_vertex() */ 
register short i; 
register Vector *p = Cur_object—>vertices; 


for (¢ = 1; i1< indez; i++) 
if (is_on_axis(p)) p++; 
else p += order; 
return 7; 
} /* end corr_vertex() */ 


Now we store the vertex list of the polyhedron. First we read all the points on the 
meridian. When the polyhedron is not convex, the computer checks whether we 
want to add the top face or the bottom face. Then we calculate all the vertices 
and store them in Coord_pool. Finally, we store the edge list and the vertex list. 
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#define CONVEX 1 (— Macros.h 

#-define HOLLOW 2 (— Macros.h 

#define Is_convez(obj)\ (— Macros.h 
((obj > geom_property == CONVEX) ? TRUE : FALSE) 

#define Store_coords(z, y, z)\ — Macros.h) 
((*Cur_coord)[X]| =x, (*Cur_coord)[Y] = y, (*Cur-coord++)({Z] = z) 
#define MA X_MERIDIAN 200 (local macro) 
float read_float() (— Proto.h) 
{ /* begin read_float() +/ 

float f; 
fscanf (Input, "%£", &f); 


return /f; 
} /* end read_float() */ 


e ° 
void must_be_keyword(keywd, obj) (— Proto.h) 
char * keywd; 


Polyhedron + obj; 


{ /* begin must_be_keyword() * { 
if (stremp(keywd, Comment)) { 
fprint P Outoar "Reading obj %s:\n", obj >name); 
forint f (Output, "keyword %s expected instead of %s\n", 
keywd, Comment); 
safe_exit(" "); 


* end if (strcmp) * 
} h id oat be heard) */ 


| . . | 
void read_convex_obj_of -rev(obj) (— Proto.h) 
Polyhedron + obj; 


{ /* begin read_convezr_obj_of-rev() */ 
short order, meridian _size; 
short i, 7; 
float sine, cosine, rot.angle = 2 * PI; 
double angle; 
float x, y, 2, tmp; 
Vector * meridian; 
Bool bottom, top; 


/* Read meridian. */ 

Fread_str(Comment); 

if (!stremp(Comment, "rot_angle")) { 
rot_.angle = PI /180 *read_float(); 
Fread_str(Comment); 


top = bottom = Is_convez(obj); 
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if (Comment(0] == '+’) { 
if (!stremp(Comment, "+top")) top = TRUE; 
else if (!stremp(Comment, "+bottom")) bottom = TRUE; 
else safe_ezit("\n+top or +bottom expected"); 
Fread_str(Comment); 
} /* end if (Comment|0]) */ 
must_be_keyword("meridian", obj); 
Alloc_array(Vector, meridian, MAX_MERIDIAN, "meridian"); 
for (i= 0; i< MAX_MERIDIAN; i++) { | 
Fread_vec(meridian|t}); 
Fread-_str(Comment); 
if (Comment|0|!= ’,’) break; 
} /* end for (i) */ 
if (¢ == MAX_MERIDIAN) 
safe_exit("Meridian too large"); 
meridian_size = i+ 1; 
must_be_keyword("order", 0b7); 
order = read_pos-int(); 
obj > vertices = Cur-coord; 
if (rot_angle < 6.28) angle = rot_angle /(order — 1); 
else angle = rot.angle /order; 


sine = sin(angle); cosine = cos(angle); 
for (i= 0; i< meridian_size; i++) { 
x = meridian(i|[X]; y = meridian(i|[Y]; 2 = meridian|:i]|Z]; 
if (x == 0&& y == 0) { /* Point on the axis. */ 
Store_coords(0, 0, z); 
} else { 


for (j = 0; 7 < order; j++) { 
Store_coords(x, y, z); 
tmp = cosine *x — sine* y; 
y = sine *x + cosine *y; 
x = tmp; 
} /* end for (j) */ 
} /* end if (x) */ 
} /* end for (2) */ 
obj > no-of-_vertices = Cur-coord — obj->vertices; 
Fread_str(Comment)); 
trivial_edge_list(obj, meridian_size, order); 
trivial_face_list(obj, meridian_size, order, bottom, top); 
obj —>no-_of edges = (Cur_edge —obj—>edges) / 2; 
Free_array(meridian, "meridian"); 
} /* end read_convexz_obj_of _rev() */ 


The edge list of the polyhedron is “trivial,” i.e., we can determine all the edges 
when we know the size of the meridian and the order. 
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eS 
void trivial_edge_list(obj, size, order) (— Proto.h) 
Polyhedron + obj; 
short size, order; 
{ /* begin trivial_edge_list() */ 
Vector *p, *q; 
short 7, j, index, other_indez; 


obj >edges = Cur-_edge; 


for (index = 1; inder <= size; index++) { 
p = corr-_vertex(indez, order); 
for (j = 0; j < 2; j++) { 
if (j == 0){ 
if (index == size && is_on_avis(p)) return ; 
otherindexr = —indez; 
}else { 
other index = index +13; 
if (index == size) return ; 


} /* end if (j == 0) */ 
if (other_index > 0) { 
q = corrvertez(other_indez, order); 
for (i= 0; i < order; i++) { 
if (is_on_axis(p)) * Cur_edge++ = p; 
else * Cur_edge++ = p + 3; 
if (ts_on_azis(q)) * Cur_edge++ = q; 
else * Curedget++ = q + 1; 
} /* end for (i) */ 
}else { 
q = corr_vertex(—other_indezx, order); 
for (i= 0; i< order; i++) { 
if (is_on_azis(p)) * Cur_edge++ = p; 
else + Curedge++ = p+i; 
if (is_on_azis(q)) * Cur_edge++ = gq; 
else { 
if (¢ < order —1)* Curedget++ = q+ i+ 1; 
else + Cur.edge++ = q; 
} /* end if (is_on_azis) */ 
} /* end for (2) */ 
} /* end if (otherindex) */ 
} /* end for (j) */ 
} /* end for (index) */ 
} /* end trivial_edge_list() */ 


The same is true for the face list. In general, an approximation to a surface of 
revolution has n = (size—1)*order faces with four vertices each plus the bottom 
face and the top face with order vertices. (When a point on the meridian lies on 
the rotation axis, the quadrilaterals degenerate into triangles. ) 
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Therefore, the highest number of pointers to Vectors we need is 4*n+ order * 2. 
These pointers can be allocated at one go, which saves both time’ and memory.® 
The following two macros store the pointers to the vertices of a triangle and a 
quadrilateral, respectively, while making effective use of the allocated space: 


#define Set3(a, b, c)\ (—+ Macros.h) 
(Cur_face—> no-_of-_vertices = 3, Cur_face++—> vertices = space, \ 
*space++ = corner + a, *space++ = corner + b,\ 

*space++ = corner + c) 


#define Set4(a, b, c, d)\ (— Macros.h) 
( Cur_face—> no_of_vertices = 4, Cur_face++-—> vertices = space, \ 
*space++ = corner + a, *space++ = corner + b,\ 

*space++ = corner + c, *space++ = corner + d) 


Now we can write a subroutine that stores the trivial face list. 


#define NO_COLOR MAX_UBYTE (—> Macros .h) 
a 
void trivial_face_list(obj, size, order, bottom, top) (— Proto.h) 


Polyhedron + obj; 
short size, order; 
Bool bottom, top; 


{ /x begin trivial_facetist() */ 
short n, j, indez; 
Vector * corner; 
short v1, v2, v3, v4; 


static Vector ««space;? 


n = (size —1) *order + 2; 

obj ->no.of faces = n; 

obj —> faces = Cur_face; 

v1 = 0; v2 = 1; v3 = 1 + order; v4 = order; 
Alloc_ptr_array(Vector, space, 4 *n+2x*order, "TRI"); 

/* Space for all the quadrilaterals (triangles) on the surface. */ 


“Memory organization can be a “bottleneck” even in fast programs. 

With many systems, the amount of bytes that are allocated by the function 
malloc() is always divisible by 8. If we allocate space for the three pointers of 
a triangle (which need 12 bytes), the system will provide 16 bytes and some 
memory will be wasted. — 

°The keyword static is essential for those local pointer variables that are used 
for a dynamic allocation of the memory that is needed outside the function. It 
prevents an error that is hard to find and that causes a program to do strange 
things or to crash later on. 
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for (index = 1; index < size; index++) { 
corner = corrvertex(index, order); 
if (is_on_axis(corner)) { 
for (j =1; j < order; j++) 
Set3(0, 1 + 5, 3); 
Set3(0, 1, order); 
else { 
if (is_on_axis(corr_vertex(index + 1, order))) { 
for (j = 1; j < order; j++) 
Set3(j — 1,7, order); 
Set3(order — 1,0, order); 
} else { 
for (j =1; j < order; j++, corner++) 
Set4(v1, v2, v3, v4); 
Set4(vl, v2 — order, v3 — order, v4); 
} /* end if (is_on_azis(corr_vertez) */ 
} /* end if (is_on_axis(corner)) */ 
} /* end for (index) */ 
if (!is_on_azxis(corr_vertez(1, order))) { 
if (!bottom) Cur_face—>color = NO_COLOR,; 
set_f(Cur_face++, corr_vertex(1, order), order, —1, &space); 
}else n—-; 
if (!ts_on_azis(corr_vertex(size, order))) { 
if (!top) Cur_face—>color = NO_COLOR; 
set_f (Cur_face++, corr_vertez(size, order), order, 1, &space); 
}else n—-; | 
obj ->no_of faces = n; 
} /* end trivial_facetist() «/ 


The top face and the bottom face are stored by means of the function 
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| 
void set_f(f, corner, n, orientation, space) (— Proto.h) 
Face « f; 
register Vector * corner; 
short n; 


short orientation; 


/* Seen from the outside of the polyhedron the face has to be oriented 


ccw. */ 
Vector ** space; 


/* Pointer to **space. This is because we want to increase **space. */ 


{ /* begin set_f() */ 
register Vector *+v; 


register short 1 = 0,7 = n —1; 
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3.0 


v = f—vertices = xspace; 
f —no-of vertices = n; 
if (orientation > 0) 
while (i < n) v[i] = corner + i++; 
else 
while je < n) v[it++] = corner + j—-; 
(*space) += 
} /* end set_f() / 


PO 


When we do not want the top face (bottom face) to be drawn, we indicate this 
by assigning the color NO.COLOR to the respective face. However, the face is 
stored and proceeded like any other face of the polyhedron, firstly, because it is 
possible to quickly determine the outline of the object by means of “frontfaces” 
and “backfaces” (Section 6.1), and secondly, because we can apply a fast hidden- 
line removal (Section 7.2). 


Surfaces of Translation 


All polyhedra that can be generated by “translational sweeping” [THAL87] will 
be called “surfaces of translation” in this book. They are defined by a planar 
base polygon and by a “translation vector.” Figure 5 shows some examples of 
such polyhedra. A special case are the parallelepipeds, which also include the 
“boxes.” A general polyhedron may be given by the data lines 


TRANSLATIONAL_SWEEP yellow translation solid 
base_points 0 20 , 0 -1.40, 0-2 0.6 , 
0-2 1.2 ,0-1.41.6,02 1.6 
trans_vector -4.5 0 0 


whereas a box may be given by the line 
BOX gray box hollow 3 3 1 +tbottom 


(“hollow” means that the top face and the bottom face are removed). A surface 
of translation is convex when the base polygon is convex. For reasons of speed, 
it is advisable to split non-convex polyhedra into convex polyhedra. (This can 
be done by a special subroutine. ) 


A polyhedron with b base points has 26 vertices and 3b edges. It has b faces 
with 4 vertices each and 2 faces with b vertices each. (Therefore, we have to 
allocate 6b pointers to the vertices.) 


In combination with the functions and macros of the previous section, it is com- 
paratively easy to store the lists: 

#define MAX_BASE 200 (local macro 

#define TRANSLATION 2 — Macros.h 

#define BOX 3 — Macros.h 
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FIGURE 5. Examples of “surfaces of translation”: these scenes consist almost entirely 
of boxes and general polyhedra of translation. 
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TY 
void read_convex_obj-of transl(obj) (— Proto.h) 
Polyhedron + 0bj; 


{ /* begin read_convex_obj-of -transl() */ 
short i, size; 
Vector trans; 
float z, y; 
Vector *p, *q, *start, *corner, *hi_coord; 
static Vector «space; /* Space for all the pointers. */ 
Bool top, bottom; 


/* Read base points until no comma is left. */ 


obj vertices = Cur_coord; 
if (obj >type == TRANSLATION) { 
Fread_str(Comment); 
must_be_keyword("base_points", obj); 
for (i= 0; i < MAX_BASE; i++) { 
Fread_vec(*Cur_coord); Cur-coord++; 
Fread_str(Comment); 
if (Comment(0| ! = ’,’) break; 
} /* end for (7) */ 
if (( == MAX_BASE) safe-exit("too many base points"); 
size = 1+ 1; 
must_be_keyword("trans_vector", obj); 
Fread_vec(trans); 
} else { /* BOX */ 
size = 4; 
trans[X] = trans[Y]| = 0; 
x = read_float(); y = read_float(); trans[Z] = read_float(); 
Store_coords(0, 0, 0); Store_coords(z, 0, 0); 
Store_coords(z, y, 0); Store-coords(0, y, 0); 
} /* end if (obj >type) */ 
/* Translate base points. */ 
hi_coord = Cur-coord; 
for (p = obj—>vertices; p < hi-_coord; Cur_coord++, p++) 
Add_vec(*Cur-coord, *p, trans); 
obj —>no_of vertices = Cur_coord — obj vertices; 
top = bottom = I s-convex(obj); 
Fread_str(Comment); 
if (Comment(0| == '+’) { 
if (!stremp(Comment, "+top")) top = TRUE; 
else if (!stremp(Comment, "+bottom")) bottom = TRUE; 
else safe-ezrit("\n+top or +bottom expected"); 
Fread_str(Comment); 
} /* end if (Comment(0]) */ 
/* Trivial edge list. */ 
obj ->edges = Cur-edge; 
start = o0bj->vertices; 
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for (¢ = 0; i< size; i++) { 
p = start+i;q¢gq =p+1; 


if (¢ == size—1)q = start; 
+Cur_edge++ = p; *Cur.edge++ = q; 
q = pt size; 


+Cur_edge++ = p; *Cur.edge++ = q; 
P=@q=prt tl; 
if («== size—1)q = start + size; 
*Cur.edge++ = p; +Cur.edge++ = gq; 

} /* end for (i) */ 

0bj >no_of edges = (Cur_edge — obj ->edges) /2; 

/* Trivial face list. */ 

0bj >no.of faces = size + 2; 

0bj > faces = Cur-face; 

/* Allocate pointer pool. */ 

Alloc_ptr_array(Vector, space, 6 * size, "TRA"); 

p = obj vertices; 

for (¢= 0, corner = p;i< size —1; i++, corner++) 
Set4(0, 1, 1 + size, size); 

corner = Dp; 

Set4(0, size, 2 * size — 1, size — 1); 

/* Bottom face and top face. +/ 

if (!bottom) Cur_face—>color = NO_COLOR; 

set_f(Cur_face++, obj ->vertices, size, —1, &space); 

if (!top) Cur_face—>color = NO-COLOR; 

set_f(Cur_face++, obj >vertices + size, size, 1, &space); 

} /* end read_convex_obj_of transl() */ 


3.6 The Intersection of Objects 


In Section 3.3, we demonstrated how data files can be written that make it easy 
for the computer to create general object lists. In Section 3.4 and in Section 3.5, 
we learned how to interpret readable data for specific kinds of primitives. The 
computer then created general object lists like in Section 3.3. In this section, we 
will deal with the creation of general ob Jects with complicated object lists by 
means of intersecting polyhedra. 


When you look at Figure 6, you can imagine that it would be a waste of time 
to write down the lists of the illustrated objects. What we can do, however, is 
to make the computer itself write the data file of the intersection polygon of two 
given polyhedra. 


Thus, we develop a function intersect_objects() with three parameters: the in- 
tersection polyhedron © and the polyhedra ©, and 6, that are to be intersected. 
The polyhedron ©. should be convex. When @, is convex, © is convex as well. 
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A pseudo-code of the task might look like this: 
1) Allocate enough space for a face list and a vertex list of 0. 
2) Determine the face list and the vertex list of © as follows: 
for all the faces f; of ©, 
Copy fi to a temporary face fo. 
for all the faces fo of ©o 
Cut off fo by means of the plane of fo. 
break the loop if fo has less than three vertices. 
if fo has at least three vertices 
Create a new face f of ©. 
Copy the vertices of fo into the vertex list of © and store the corre- 
sponding pointers in the vertex list of f. For each vertex, make sure 
that it has not been stored before (or else most vertices will be stored 
two or three times). 
if ©, and @2 are convex 
Swap ©, and @2 and repeat the process. 
else 
for all the faces fo of Qo 
for all the faces f of © that have been found so far 
Check if an edge of f is in the plane of fo. 
If there is such an edge, store it. 
if at least three edges are stored 
Create a new face f of 0. 
Concatenate all the edges to a closed polygon and store the point- 
ers to the vertices in the vertex list of f. 
3) Allocate enough space for the edge list of ©. 
Extract the trivial edge list from the face list. 
4) Write a data file. 


Dump the lists of the object © in the format that is described in Sec- 
tion 3.2. 


The corresponding C code looks like this: 
Vector * Add_vertices, *Cur_add; 
/* A pool for the coordinates of temporary vertices 
and a pointer to a vertex in this pool. +/ 


#define Alloc_string(char_ptr, n)\ (— Macros.h) 
Alloc_array(char , char_ptr, n+ 1, "str")1° 

#define Mazimum(z, y) ( (x) < (y) ? (z) : (y) ) (— Macros.h) 

#define Minimum(z, y) ( (x) > (y) ? (x) : (y) ) (— Macros.h) 


°A string str with n = strlen(str) is stored as str + "\0". Therefore, it needs 
n+1 instead of n characters. In most cases, the system function malloc() allocates 
enough space anyway, because it takes the next number no > n that is divisible 
by 8, so that no error will occur, even if we forget about the additional byte. 


However, for n = no (n mod 8 = 0), this may produce an error that is hard to 
nd. 
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FIGURE 6. Some examples of the intersection of two polyhedra. 
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void normal_vector(n, points) 


{ 


} 


Vector n, * * points; 


/* begin normal_vector() */ 
register float len; 

register Vector +a, *b, *c; 
Vector ab, ac; 


a = points|0|; b= points(1|; c= points(2]; 
Subt_vec(ab, *a, *b); Subt_vec(ac, *a, *c); 
Cross-product(n, ab, ac); 
len = Length(n); 
if (len > 0) { 

n[X] /= len; n[Y] / = len; n[Z] / = len; 
} else 

Print(" warning: could not normalize Vector!"); 
/* end normal_vector() */ 


typedef struct { 


Vector *vl1, *v2; /* Pointers to the vertices of the edge. */ 


} Edge; 


void intersect_objects(obj, 0bj1, 0bj2) 


{ 


Polyhedron *o0bj, /* The intersection. */ | 
+ 0bj1, /* Does not have to be convex. */ 
+ 0bj2; /* Should be convex. */ 

/* begin intersect_objects() */ 

Face + f1, *hi.f1, *f2; /* Faces of obj1 and 0bj2. */ 

Face f0; /* A temporary face. */ 

Face * f, *hi.f; /* Faces of obj. */ 

short 1, n, ™; 

Plane + plane_pool, «plane, *hi_plane; 

static Vector vtz_ptr_pooll; 

Polyhedron * temp; 


Alloc_string(obj >name, strlen("INTERSECTION" )); 
strcpy(obj name, " INTERSECTION"); 

obj ->geom_property = obj1-—>geom-_property; 

f = obj-—>faces = Cur_face; 

obj > vertices = obj ->hi_coord = Cur-_coord; 
obj ->edges = Cur_edge; 


(— Proto.h) 


(— Types.h) 


(— Proto.h) 
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/* Create section planes. */ 
if (Is.convex(obj1)) 
n = Mazximum(obj1—>no-_of -faces, 0bj2—>no_of _faces); 
else 
= 0bj2-—>no-0f _faces; 
Allocarray(Plane, plane-pool, n, "planepool"); 


Alloc_ptr_array(Vector, f0.vertices, MAX_POLY_SIZE, "tf0")); 
Alloc_array(Vector, Add-_vertices, 1000, "£0"); 
Alloc_ptr_array(Vector, vtx_ptr_pool, 2000, "space"); 

Cur.add = Add_vertices; 


for (m = 0; m < 2; m++) { 
hi_plane = (plane = plane_pool) + obj2 > no-of faces; 
f2 = obj2—> faces; 
for (; plane < hi_plane; plane++, f2++) { 
normal_vector(plane—>normal, f2—>vertices); _ 
plane—>cnst = Dot-_product(plane—>normal, + f2—> vertices|0}); 
} /* end for (plane) */ 


/* Cut all the faces of 0bj1. */ 
hi_fl = (f1 = obj1>faces) + obj1—>no-of_faces; 
for (; fl < hi_f1; f1++) { 

/* Copy f1 to f0. */ 


n = f0.no_of vertices = f1—>no-0f -vertices; 
for (¢= 0; 7< n; i++) 
f0.vertices[i] = fl—vertices|i); 


/* Truncate f0. */ 

for (plane = plane-pool; plane < hi-plane; plane++) { 
cut_face.withplane(&f0, plane); 
if (f0.no.ofvertices < 3) break; 

} /* end for (plane) */ 

/* Copy f0 to a new face f of obj. */ 

if (f0.no.of vertices >= 3) { 
n = f->noof-vertices = f0.no_of vertices; 
f—vertices = vtx_ptr_pool; vtz_ptr_pool + = n; 
for ({= 0; i< n; i++) 

f—>vertices|i] = corr_ptr(f0.vertices|i], obj); 

f++; 

} /* end if (f0) «/ 

} /x end for (f1) */ 


90 Chapter 3. How to Describe Three-Dimensional Objects 


if (Is.convex(obj1)) Swap(obj1, 0bj2); 
else 
Edge * edges; 
Face * prev_f; 
Alloc_array(Edge, edges, MAX._POLY_SIZE, "edges"); 
hif = f; 
for (plane = plane_pool; plane < hi_plane; plane++) { 
prev-f = obj-—> faces; n = QO; 
for (; prev-f < hi_f; prev-f++) 
if (edge_in_plane(&edges[n|, prev_f, plane)) n++4; 
if (n >= 3) { 
f—vertices = vtz_ptr_pool; vtx_ptr_pool + = n; 
if (concat_to_polygons(&i, & f —>no-_of vertices, 
& f >vertices, n, edges, FALSE)) { 
if (f—>vertices|0]| == f —>vertices|n}) 
f >no-of -vertices——; 
f++; 
} /* end if (concat) */ 
} /* end if (n) */ 
} /* end for (plane) +/ 
break; 
} /* end if (Is.convex) */ 
} /* end for (m) */ 
obj —>no-of -vertices = obj-—>hi-_coord — obj vertices; 
obj —>no-_of faces = f — obj — faces; 
get_edges_from_facelist(ob7); 
Free_array(plane_pool, "PLP"); 
Free_array(f0.vertices, "£0v"); 
write_datafile(obj); 
safe_exit("Your data file is ready."); 
}  /* end inter sect_objects() */ 


The function cut_face_-with_plane() has the code 


void cut_face_with_plane(f, plane) (— Proto.h) 
Face +f; 


Plane + plane; 


{ /* begin cut_face_-with_plane() */ 
short n = f—->no-_of_vertices; 
Vector #uv = f—vertices; 
short to_be-cut = 0; 
short i= 0, j, k = 0; 

Vector *tmp_ptr|MAX_POLY_SIZEH); 
short side| MAX_POLY_SIZE); 
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for (t= 0; i< n; i++, v++) 
if ((side[i] = Which_side(#«v, *plane)) > 0) to_be_cut++; 


if (!to_be_cut) 
return ; 

else if (to_be.cut == n) { 
f—>no-of -vertices = 0; 
return ; 

} else 
Vector diff, *vl, *v2; 
float t; 
Bool parallel; 


k = 0; 
v= f > vertices; 
for (i= 0, j = ; i< in i++, j++) { 


if G 

if (sideli) i 0 &ke side > 0) continue; 
vil = vilij; v2 = v 

if (sideli] < 0) 








tmp-ptr[k++] = v{i]; 
if (side[i]!= side[j]) { 
Subt_vec(dif f, *v1, *v2); 
sect_line_and_plane(* Cur_add, &t, &parallel, *v1, dif f, plane); 
tmp-ptr([k] = ptrto_vertex(); 
if (k == 0 || tmp_ptr[k] != tmp-_ptr[k — 1]) k+4; 
} /* end if (side[z]) */ 
} /* end for (7) */ 
f—>no-of vertices = k; 
v= f—->vertices; 
for (i= 0; i< k; i++) 
v[é] = tmp-ptr{i); 
} /* end if (!to_be-cut) */ 
} /* end cut_face_with_plane() */ 


The function 


Vector * ptr_to_vertez() (— Proto.h) 
{ /* begin ptr_to_vertex() */ 
register Vector *v = Add_vertices; 


for (; v < Cur-_add; v++) 
if (close_together(v, Cur_add)) 
return vw; 
Cur_add++; 
return wv; 
} /* end ptr_to_vertex() */ 
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checks whether the vertex has been stored before and returns the corresponding 
pointer to the vertex. It calls a function 


Bool close_together(a, 6) (— Proto.n) 
register Vector +a, +b; 

{ /* begin close_together() */ 
register short i; 


for (i= 0; i< 3; i++) 
if (fabs((+*a)[i] — (+*b)[7]) > le—3)return FALSE; 
return TRUE; 
} /* end close_together() */ 


which determines whether two points have the same coordinates. (Because of 
the limited accuracy of floating point calculations, we have to admit a certain 
tolerance. ) 


The function corr_ptr() picks a vertex from the temporary coordinate pool and 
copies it to the vertex list of the object: 


Vector + corr_ptr(v, obj) | (— Proto.h) 
Vector *v; 
Polyhedron «x obj; 

{ /* begin corr_ptr() */ 
register Vector *v0 = obj—>vertices, thi.v0 = obj-—>hi_coord; 


for (; v0 < hi-v0; v0++) 
if (closetogether(v0, v)) return v0; 
/* Vertex has to be copied into obj > vertices. */ 
Copy-vec(*v0, *v); 
obj —> hi_coord++; 
return v0; 
}  /* end corr_ptr() */ 


To find out whether a face has an edge on a plane, we use the function 


| | 
Bool edge_in_plane(edge, face, plane) (— Proto.h) 
Edge «edge; 
Face * face; 


Plane «plane; 
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{ /* begin edge-in_plane() */ 
register Vector *«*v = face—vertices, 
kxhiv = v+ face—->no-of vertices; 
register Vector +p, #n = (Vector *) plane—normal; 
register float c= plane>cnst; 


for (++v; vu < hiv; v++t) { 
p = *v; 
if (fabs(Dotproduct(*p, *n) —c) < 1le—4) break; 
} /* end for (v) */ 
if (v++ == hiv) return FALSE; 
edge—>v1 = p; 
edge—>v2 = p = (u< hiv)? *v : face—vertices(0); 
return (fabs(Dot-product(xp, *n) —c) < le-4); 
} /* end edge-in-_plane() */ 


The important Bool function concat_to_polygons() is listed in Section 6.1. 
Finally, we give the listing of a function that writes the desired data file: 


#define P_vec(v)\ (local macro) 
forint f (df, "¥%8.3£.%8.3£%8.3£", (v)[X], (v)[¥], (v)[Z]) 

| 

void write_datafile(obj) (— Proto.h) 


Polyhedron * bj; 

{ /* begin writedatafile() «/ 
FILE «x df; 
short i, j, n, idz; 
Vector *v, *hi.v; 
Face * f, *hi_f; 
Vector +e, *hi_e; 


df = safe_open("intersect.dat", "w"), 
forint f(Output, "filename = intersect .dat\n"); 
forintf (df, "4su", 0bj >name); 
forintf (df, "%susu", "magenta"); 
forintf (df, "general,,"); 
if (Isconvex(obj)) fprintf(df, "solid\n"); 
else fprintf(df, "hollow\n"); 
forintf (df, "uuuvertices"); 
v= obj—>vertices; hiv = obj —>hi-coord; 
for (i= 0; v< hiv; v++t) { 
if (i> 0) fprintf (df, "usu"); 
if (i++ %2 == 0) fprintf(df, "\n uw"); 
P_vec(*v); 
} /* end for (i) */ 
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fprintf(df, "\n uwuedges\n uu"); 
hi.e = (e= obj >edges) + 2 *obj—>no_of_edges; 
for (i= 0; e< hie; ) { 
fprintf(df, " uw"); 
for (j = 0; 7 < 2; j++, e++) { 
idx = *e — obj vertices; 
fprintf(df, "%4ai", idx); 
} /* end for (j) */ 
if (e< hie—1) fprintf(df,".u"); 
if (++i % 5 _— = 0) forint f (df, "\n uu ; 
} /* end for (7) */ 
forint f (df, "\n uwufaces\n"); 
hi-f = (f = obj > faces) + obj >no-of -faces; 
for (; f< hi-f; f++) { 
short prev.idz, firstidz; 


if ((n = f—->no-of-_vertices) < 3) continue; 
hi.e= (e= f+vertices)+ n —1, 
forint f(df, "uooo180"); 
previdzr = —1; 
for (i= 0; e<= hi-_e; e++) { 
if (++i1%12 == 0) forintf(df, "\n oo"); 
idx = xe — obj >vertices; 
if (e== f—vertices) firstidt = idz; 
if (idx != prev_idz && \(e == hi_e && idx == first_idz)) 
fprintf(df, "“4a.", ida); 
prev.idx = idz; 
} /* end for (i) */ 
if (f+1l<hif && (f +1)—>no-of vertices) 
forint (df, " su"); 
fprintf(df,"\n"); 
} /* end for (f < hi_f) */ 
fclose(df); 
} /* end write_datafile() */ 


The data file for the two cubes in Figure 6 looks like this: 
CUBE1 yellow box solid 6 6 6 
translation -3 -3 -3 
CUBE2 green box solid 6 6 6 
translation -3 -3 -3 
rotation x 40 rotation z 20 


To create the pencil in Figure 6, we used the following file: 
CONE gray revolution solid 
meridian 5 0 -10, 5 00, 00 ii order 45 
PRISM yellow revolution solid 
meridian 4 0 -12, 4 0 12 order 6 


4 
Graphics Output 


In this chapter, we will see how we can write graphics programs that are more 
or less independent of the hardware that is used. If we want to adapt these 
programs to different kinds of computers, we only have to change a few lines in 
one of the include files and in the system-dependent module. 


We will create color palettes and use them for the shading of our facets. For the 
shade, we will take into account factors like the angle of incidence of the facet 
with the light rays and the distance from the light source. 


Furthermore, we will learn how to write a program that allows us to manipulate 
a wireframe model of an arbitrary scene. 


Graphics Hardware 


Before we can make any drawings on the screen, we have to know the graph- 
ics commands. These commands are system-dependent. Graphics workstations 
provide a lot of functions, most of which are executed by graphics coprocessors. 
This helps to speed up the programs considerably. Less sophisticated computers 
are only supplied with very few graphics commands so that everything has to be 
done by the software. 


We will try to write programs that use as few graphics-dependent functions and 
macros as possible and that still allow the program to take advantage of the 
graphics hardware. You will see that we do not need a lot of these commands. 
They should all be written into the include file G.macros.h. When it is neces- 
sary to write functions, the macros just call these system-dependent functions 
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4.2 





that are collected by the system-dependent module g_functs.c. The include file 
G._macros.h has to be included in the file 3d_std.h (Section 1.1), whereas the 
object file g-functs.o has to be linked with the program. 


In order to reproduce all the features presented in this book, you need a computer 
that 


e is able to create palette colors by means of RGB values (the more, the better, 
with a minimum of 16 for the shading). 


e is able to set pixels in these colors on the screen. The compiler should provide 
a function for the drawing of a line between two screen points and, if possible, 
a function for the filling of convex polygons. 


e has an acceptable screen resolution (the absolute minimum is 320 x 200 like 
on a Standard-VGA-Card for PCs), if possible with two “pages” for “double 
buffering” (page flipping). 


System-Dependent Macros and Functions 


Throughout the book, we will only use our own macro names, even if we want to 
do something that depends on the hardware that is used. If you want to adapt the 
program to any specific graphics computer you only have to replace the macros 
listed in this chapter. In Appendix A.1 you will find the corresponding listings 
of the following macros (and functions) for a variety of different computers in 
connection with certain compilers. Some compilers might use the same names as 
we do, and in order to avoid that, we start every macro name with a “G_”: 


(void) G_open_graphics (void); (— G.macros.h) 
/* Open a graphics window/screen. For some computers this means that 
the whole screen switches over to graphics mode, on others (with multi- 

tasking or a separate graphics monitor), part of the screen is reserved for 

your drawings. When the window is opened, we let the global variable 
Graph_on be TRUE. This is important for safe exits from the program. 


* 

(void) G_close_graphics (void); (— G_macros.h) 
/* Close the open screen. */ 

(void) G_clear_screen(short col); (— Gmacros.h) 
/* Clear screen in color col. «/ 

(void) G_swap_screens (void); (— G.macros.h) 


/* Turn over screen pages (if there is more than one page). This is also 
called “double buffering.” The availability of a double-buffer mode is 
important for animation. In double-buffer mode, the framebuffer is split 
into a frontbuffer and a backbuffer. While the image is drawn into the 
backbuffer, the frontbuffer is displayed. The function G_swap-_screens() 
will exchange the buffers. «/ 
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(void) G_create.RGB_color(short n,short r,short g,short b); 

(— G.macros.h) 
/* Create a color given by RGB values (red, green, blue) and store it as 
the n-th color in a color lookup-table. Full RGB mode allows detailed, 
high-quality renderings of full color displays. However, only few graphics 
computers have that much video memory. The use of color maps is an 
economical way of using fewer bits per pixel, so that 2” colors can be 

displayed at the same time (where n is the number of bit planes). */ 


short Cur-color; (— Globals.h) 
/* Current pixel color. This pixel color is set when we call the following 
macro G_set_color(). */ 


(void) G_set_color(short 1); (— G.macros.h) 
/* Set the n-th color from the color lookup-table before a line is drawn or a 
polygon is filled. */ 
(short ) G_get_pizel_color(short 2, short y); (— G.macros.h) 
/* Return the index from the color lookup-table for the pixel position (z, y). 
This function is necessary only for the drawing of “rubber bands” (Sec- 
tion 4.6). */ 
(void) G_set_pizel(short «x, short y); (— G.macros.h) 
/* Set pixel in current color. */ 


/* Commands for the drawing of a (poly)line: */ 


(void) G_move_cy(short z, short y); (— G_macros.h) 
/* Move to (az, y). */ 

(void) G_draw_ry(short z, short y);_ (— G_macros.h) 
/* Draw a line to (x, y). */ | 

(void) G_move(Vector v); (— G.macros.h) 
/* Move to the first vertex of a (poly)line. */ 

(void) G_draw(Vector v); (— G_macros.h) 


/* Draw to the next vertex of a (poly)line. */ 
/* Commands for the filling of a (convex) polygon: */ 


(void) G_move_area(Vector v); (— G_macros.h) 
/* Buffer first vertex of a polygon. */ 
(void) G_draw_area (Vector v); (— G_macros.h) 
/* Buffer next vertex. */ 
(void) G_close_area (void); (— G_macros.h) 


/* Fill buffered (convex) polygon. +/ 


/* For the manipulation of the scene by means of the keyboard: */ 
(Ubyte) G_key_pressed (void); (— G.macros.h) 
/* Returns 0 if no key is pressed, otherwise it returns the ASCII-code of the 
key that is pressed. */ 


/* Finally, a command for an acoustic signal: */ 


(void) G_beep (void); (— G.macros.h) 
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With the help of these basic functions, we can write all of the other functions 
we need for the graphics output. A function for the connection of two points on 
the screen, for example, might look like this: 


void quick_line(p, q) | (= Proto.h) 
register float *p, *q; 

{ /* begin quick_line() */ 
G_move(p), G_draw(q); 

} /* end quick_line() */ 


A function for the filling of polygons might have the code 

void fill_poly3(n, poly) (for the time being!) 
short n; /* Number of vertices. */ 
register Vector *poly; /* Array of vectors. */ 


register Vector *hi_poly = poly +n; 

G_move_area(xpoly); 

for (poly++; poly < hi_poly; poly++)! 
G_draw-area(*poly); 

G_close_area(); 


j 


When the coordinates of the polygon are only two-dimensional, we have to use 
another function: 
void fill_poly2(n, poly) (for the time being!) 
short n; /* Number of vertices. */ 
register Vector2 «poly; /* Array of vectors. */ 


register Vector2 *hi_poly = poly +n; 


: /* Same code as above.” */ 


Without any mentionable loss of speed, the functions fill_poly3() and fill_poly2() 
can be replaced by a single function fill_poly(). This method was also used for 
the function intersect_lines() (Section 1.3). One advantage of such a compres- 
sion of codes is that we do not have to change several parts of the code when we 
want to elaborate the function. 


‘Even though the variable poly is a pointer, any change of poly is undone 
outside the function fill_poly(). We can only change *poly, i.e., the contents of 
the vector. 

*For the macros G_move_area() and G_draw_area(), it does not make any 
difference whether poly is a two-dimensional Vector2 or a three-dimensional 
Vector, because both types are interpreted as pointers to a float and only the 
first two elements of the array are taken. 
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void fill_poly(n, poly, dim) (— Proto.h) 
short n; 
register float *poly; 
register short dim; /* Two or three. «/ 


{ /* begin fill_poly() */ 
register float +*hi_poly = poly + dim * n; 


G_move-area(poly);° 

for (poly += dim; poly < hi_poly; poly += dim) 
G_draw-area(poly); 

G_close_area(); 


} /* end fill_poly() */ 


How to Create Color Palettes and How to Use Them 


Consider a green polyhedron. Its faces will appear in hues or shades of green - 
the collection of these shades is called a green palette. Even though the human 
eye can distinguish hundreds of different “greens,” a comparatively small number 
of different shades is sufficient for our purposes (the pictures in this book were 
created with palettes of 32 different shades). Sophisticated shading models like 
“ray tracing” [GLAS90] or “Phong shading” [BUIT75] may use larger palettes. 


The problem is that we can only display a limited number of colors on the screen 
at one and the same time. This is why we prefer several smaller palettes to one 
or two huge palettes. To give you an example: many computers can display 256 
different colors on the screen.’ In this case, we will use 8 parent palettes with 32 
shades each plus a variety of additional palettes created out of the prototypes 
(once we have created a “green palette,” we can extract a “light green” palette 
and a “dark green” palette without wasting any further video memory). 


Every color can be synthesized by means of a red component R, a green com- 
ponent G and a blue component B (0 < R,G, B < 1). These three components 
form a Vector. Each color in a certain palette has a RGB value somewhere in 
between a “lower” RGB vector and an “upper” RGB vector. (In [ROGE85] or 
[PURG89] you can find some other possibilities of defining a color between two 
RGB vectors. A system that is more intuitive, and thus, more user-oriented, is 


3Now we must not write «poly any more, because this would be a float, 
whereas the macro expects a Vector, i.e., a pointer to a float. 

“This requires at least 8-bit planes for single buffering and 16-bit planes for 
double buffering (page flipping). 
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the HLS system (Hue, Lightness, Saturation).) If we have n shades in a palette 
(lower_rgb — upper_rgb), the k-th shade can be interpolated linearly: 


—- b-—l yb 
>) _ 

rgb(k) = lower_rgb + k. ——eeoeer (1) 
_ 


———_} 
delta_r gb (constant) 


This enables us to create any kind of palette by means of a function 
make_spectrum(). This function uses several macros that will turn out to be 
useful in the following chapters as well: 


#define Scale_vec(r, v, k)\ : 
((r)[X] = k + (v)[X], (r)[¥] =k * (W)[Y], (r)[Z] = & * (w)[Z]) 
#define Round_vec(r, v)\ —> Macros.h) 
((r)[X] = (v)[X] + 0.5, (r)[¥] = (v)[Y] + 0.5, (r)[Z] = (v)[Z] + 0.5) 
/* In C type conversion is automatic. When i is an integer variable and 
f is a float variable, the assignment i = f + 0.5; quietly converts i 
into the round value of f. «/ 


/* First, we predefine the parent palettes we want to have at our disposal (the 
color names are of course only a suggestion): */ 


typedef struct { /+ Palette +/ 
Ubyte indez; . 
Bool in_use; 
Vector lower_rgb, upper-_rgb; 
char *name; 


(— Macros.h) 


} Palette; (— Types.h) 
#ifdef MAIN 
Palette Parent_palette[8] = { (— Globals.h)° 
/* index in_use lower_rgb upper rgb name */ 
0, FALSE, 0.00, 0.00, 0.00, 1.00, 1.00, 1.00, "gray", 
1, FALSE, 0.00, 0.30, 0.00, 0.80, 1.00, 0.80, "green", 
2, FALSE, 0.50, 0.30, 0.00, 1.00, 1.00,0.50, —"yeaow", 
3, FALSE, 0.00, 0.25, 0.45, 0.70, 0.70, 1.00, "blue", 
4, FALSE, 0.50, 0.00, 0.25, 1.00, 0.85, 0.80, "pink", 
5, FALSE, 0.00, 0.25, 0.25, 0.50, 1.00, 1.00, "cyan", 
6, FALSE, 0.10, 0.10, 0.10, 1.00, 0.20, 1.00, "magenta", 
7, FALSE, 0.50, 0.15, 0.00, 1.00, 0.60, 0.40, "orange" 
}; /x end Parent_palette «/ 
#else 
Palette Parent_palette|8}; 
#endif 


This requires at least 8-bit planes for single buffering and 16-bit planes for 
double buffering (page flipping). 
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a | 
void make_spectrum(pal, start.idz, n) (—> Proto.h) 
Palette *pal; /* Pointer to palette. +/ 
short start_idz, n; 
/* The palette will be stored in the color lookup-table between the in- 
dices start_index and start_index +n. */ 


{ /* begin make_spectrum() */ 

short color_idz, hi_color_idz; /* Index of the current color. +/ 

Vector 
lower_rgb, upper_rgb, 
cur_rgb, /* Current RGB in between these vectors. */ 
delta_rgb; /* “Increase of color.” */ 

short rgb[3], prev_rgb|3]; 
/* Current triplet of round RGB values, previous triplet. a / 

color_idx = startidz; 

/* The following constants MAX_COLORS and RGB_RANGE are defined 
in the system-dependent include file G_macros.h: 
MAX_COLORS is the number of colors that can be displayed simulta- 
neously, RGB_RANGE is the number of values for the red, green and 
blue components of a color. Thus, the colors that are to be displayed can 
be chosen from of a palette of (RGB_RANGE)? colors. */ 


/* Copy extreme color vectors from table and fit them into RGB_RANGE. 
*/ 
Scale_vec(lower_rgb, pal—>lower_rgb, RGB_RANGE); 
Scale_vec(upper_rgb, pal—>upper_rgb, RGB_RANGE); 
/* Calculate delta_rgb. */ 
Subt_vec(delta_rgb, lower_rgb, upper_rgb); 
Scale_vec(delta_rgb, delta_rgb, 1.0/n); 
/* Initialize previous color with impossible RGB values. */ 
prev_rgb|[0| = prev_rgb[1] = prev_rgb[2] = —1; 
Copy-vec(cur_rgb, lower-rgb); /* We start with lower_rgb. */ 
hi_coloridx = Minimum(MAX_COLORS, startidz +n); 
for (; color_idx < hi-color-idz®; color_idz++) { 
Round_vec(rgb, cur-_rgb); 

/* Take the nearest possible color. Since the RGB values are rounded 
off, it may happen that a palette has two identical colors. In order 
to avoid that, we compare the current color with the previous one. 
If they are identical, we increase one of the three components by 
one. */ 


6Note that in C the loop 
for (i= 0; i< complicated expression; 1++-) 
is slower than the loop 
for (i= 0; i< i_maz;, i++) 
because its upper limit will be calculated every time. 


102 


Chapter 4. Graphics Output 


if (rgb[0] == prev_rgb[0| && 
rgb[1] == prev_rgb[1| && rgb|2] == prev_rgb[2]) { 
if (rgb[0] < RGB_RANGE) ++rgb\0]; 
else if (rgb[1] < RGB_RANGE) ++rgb({1); 
else if (rgb[2] < RGB_RANGE) ++rgb(2]; 

} /* end if (rgb...) */ 

G_create_RGB(color_idz, rgb[0], rgb[1], rgb[2)); 

Copy_vec(prev_rgb, rgb); 

Add_vec(cur_rgb, cur_rgb, delta_rgb); 

} /* end for (coloridx) */ 
}  /* end make_spectrum() */ 


Now it is easy to create all the necessary palettes according to our predefined 
standard colors. In order to have fast access to all the colors, we introduce an 
array of pointers +Map-_color| |: 


#-define MAX_PAL\ 
((MAX.COLORS — COLOR_OFFSET)/PAL_SIZE)' (— Macros .h) 


short *Map-color|3 * MAX_-PAL]; (— Globals -h) 
/* PAL_SIZE and COLOR_OFFSET are defined in G_macros.h. Default for 
COLOR_OFFSET is zero. If your computer has enough bit planes, you 
can skip the first color entries. These colors are usually predefined by the 
system. Otherwise your “Desk Top” alters the colors. The reason why 
we allocate space for 3 * MAX_PAL palettes is that from each parent 
palette we can extract two “subpalettes.” However, they have only half 
of the shade range. +/ 


void create_palettes() (— Proto.h) 


{ /x begin create_palettes() */ 
register short pal, *dark, +*bright; 
short i, p0) = COLOR_OFFSET, idz; 


for (idx =0; idx < MAX_PAL; idz++) { 
make_spectrum(Parent_palette +idz, p0, PAL_SIZB); 
/* Allocate space for three palettes. x / 
Alloc_array(short , Map-_color|idz],3 * PAL_SIZE,” pal” ); 
pal = Map-colorjidz]; 
bright = Map-colorjidz + MAX_PAL| = pal + PAL-_SIZE; 
dark = Map-colorjidx + 2* MAX_PAL|] = pal +2 PAL_SIZE; 


*The C preprocessor will replace the constant MAX_PAL by the result of the 
division (MAX_COLORS-COLOR_OFFSET)/PALSIZE every time it appears in 
the code. The constants PAL_SIZE and COLOR_OF FSET are system-dependent 
and have to be defined in G_macros.h. 
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for (i =0; i< PAL_SIZE, i++) 
pal[i] = p0 + 4; 

p0 += PAL_SIZE; 

/* We get two more palettes “for free,” even though these secondary 
palettes only have half of the shade range of the “parent palette.” 
Thus, they should only be used when you run out of parent palettes. 


*/ 


for (i= 0; i < PAL_SIZE, i++) { 

/* The dark subpalette consists of the shades in the lower half of 
the parent palette pal, and the light subpalette consists of the 
shades in the upper half (Figure 1). «/ 

dark|i] = pal[i/2); 

bright|i] = pal[( PAL_SIZE + 1) /2]; 

} /* end for (i...) */ 
} /* end for (ida...) */ 
}  /* end create_palettes() */ 





FIGURE 1. How to extract two “subpalettes” from a “parent palette.” 


Remember that we wrote the color of our object into the datafile itself (Sec- 
tion 3.3 and Section 3.6). Here is the listing of a function that interprets the 
name of the color palette and that returns the index of the corresponding palette: 


Ubyte color_index(color_name) | (— Proto.h) 
char *color_name; 


{ /* begin color_index() */ 
register Palette *pal, *hi_pal:; 


/* Is color.name the name of a parent palette? */ 
hi_pal = Parent_palette + MAX_PAL; 
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for (pal = Parent-_palette; pal < hi-pal; pal++)_ 
if (!stremp(pal—>name, color_name)) 
return pal—indez; 
/x Is color.name the name of a subpalette? */ 
if (!strncmp("light", color_name, 5)) { 
/* “lightgray", "lightgreen", "“lightyellow" etc. +/ 
color_name += 5; /* What is the color name after "light"? */ 
for (pal = Parent_palette; pal < hi_pal; pal++) 
if (!stremp(pal—>name, color_name) 
return pal—>index + MAX_PAL; 
} /* end if +/ 
if (!strncmp("dark", color_name, 4)) { 
/* “darkgray", “darkgreen", "darkyellow" etc. */ 
color_name += 4; /* What is the color name after "dark"? «/ 
for (pal = Parent_palette; pal < hi_pal; pal++) 
if (!stremp(pal—>name, color_name) 
return pal—>index + 2* MAX_PAL; 
} /* end if */ 
fprintf (Output, "color %s not found (gray taken)\n", color_name); 
return Parent_palette—>indez; 
} /* end color_index() */ 


If we have 
idx = color_index(color_name); 
in our code, we let 


Parent_palettelidr % MAX_PAL].inuse = TRUE; 


so that the program knows whether the palette is really going to be used. This 
allows us to create larger palettes. 


Finally, if we want to set a particular shade of a color palette, we write 
G_set_color (Map-color|palette]|shade_value]); 
or we use the macro 


#define Set_map_color(pal, shade) \ (— Macros.h) 
G_set_color(Map-color|pal]|shade}); 


and write 
Set_map-color(palette, shade_value); 
As a special case, the color of the background can be defined by 
#define BACKGROUND Map-color(0]|0] (— Macros.h) 
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4.4 Wire Frames and Depth Cuing 


In Chapter 3, we learned how to create vertex lists, edge lists and face lists of 
the objects we want to draw. In order to draw a wireframe, we simply have to 
draw all the edges of all the polyhedra we want to display: 


void draw_wire frame() (— Proto.h) 


{ /* begin draw_wireframe() */ 
register Vector *vl, +v2; /* Pointers to Coord_pool. */ 
register Vector xptr, +hi_ptr; /* Pointer to Edge-pool. */ 
Polyhedron +0bj = Object_pool, *hi.obj = obj + Total_objects; 


fill_screen_pool(); 
for (; obj < hiobj; obj++) { 
hiptr = (ptr = obj > edges) + 2 * obj ->no_of -edges; 
Set_map_color (obj ->color index, PAL_SIZE/2); 
while (pir < hi_ptr) { 
vl = Screen_coords(*ptr++);® 
v2 = Screen_coords(*ptr++); 
draw_line(*v1, *v2); 
} /* end while */ 
} /* end for (obj) */ 
} /* end draw_wireframe() */ 


(After the screen pool is filled, the pointer draw_line points either to quick_line() 
or to clip3d_line() .) | 


Wireframes are a bit confusing, especially when we deal with unusual views. On 
the other hand, they enable us to quickly move and rotate a scene before we do 
the final rendering. 


If we apply the so-called “depth cuing” [ROGE87] to the wireframe, the pictures 
look much more three-dimensional (Figure 2). The color of the image of a point 
(i.e., a “pixel”) is not only determined by the color of the object the point 
belongs to, but it is also influenced by the distance from the projection center. 
To save calculation time, this distance may be replaced by the distance from the 


8For less experienced C programmers: the operation ++ is done after verter 
has been assigned, because ++ stands after ptr. Be careful with such abbrevi- 
ations of the code when you use macros! A typical example of an error that is 
hard to be found is the line 

Add_vec(a, a, *b++); 
(Where a and +b are Vectors.) The value of 6 will increase by 3 instead of 1 at 
the end of the line, because the macro Add_vec() will replace this line by 3 lines. 
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projection plane (the latter being the third coordinate of the point in the screen 
system). 


If we want to draw a line from the image of a point P to the image of a point Q, 
theoretically, we have to calculate the depths of several points between P and Q, 
which takes a lot of time. Therefore, we will only calculate the average depth of 
the points between P and Q (i.e., the arithmetic mean of the z-coordinates of P 
and @ in the screen system). The result still looks much better than an ordinary 
wireframe. 





FIGURE 2. An ordinary wireframe and a depth-cued wireframe. 


Some graphics workstations are provided with hardware depth cuing. In this 
case you should use the hardware according to the user’s manual. Usually, it is 
enough to set a Boolean variable depthcuing (or similar) TRUE, to store the 
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minimum and the maximum depths in some predefined variables and to indicate 
the color palette by its start index and its last index in the color lookup-table. 
This may be done by the macros 


7#-define HARDWARE_DEPTH_CUING 


(void) G_depth_cuing (on_of f); (— G._macros.h) 
/* TRUE or FALSE. */ 

(void) G_depths_for.depth_cuing (min_depth, max_depth); (— G.macros.h) 

(void) G-_colors_for_depth_cuing (min_color, maz_color); (— G._macros.h) 


Before we draw the depth-cued wireframe, we allocate and fill a “color pool” 
with the shade values of all the points: 


Ubyte Init(Color_pool, NULL); (— Globals.h) 

float Min_depth, Maz_depth, Total_depth; (— Globals.h) 
/* We need these values for the shading of the faces. */ 

#define Tw, z, syst)\ (— Macros.h) 


((w) = (z) /(Dist[syst] — (z))) 
/* Apply the transformation T2: Formula (2.3.9). */ 
#define UndoT2(z, w, syst)\ (— Macros.h) 
((z) = (w) * Dist[syst] /(1 + (w))) 
/* Apply the inverse transformation T;': Formula (2.3.10). */ 


void fill_color_pool() (— Proto.h) 


{ /* begin fill_color_pool() */ 
register float min_z, maz-_z; 
register float *z = &Screen_pool(0|[Z]; 
float *hi_z = &Screen_pool|Total_vertices||Z]; 
register Ubyte *cur_color; 
register float lambda; 
float z1, 22, z0; 
/* First determine the extreme depths. */ 
if (!Color_pool) 
Alloc_array(Ubyte, Color-pool, Total_vertices, "Color_pool"); 
cur_color = Color_pool; 
MIN_Z = MAL_Z = *Z; 
for (z += 3; z < hi_z; z+=3) {9 
if (xz < min_z) min_z = *z; 
else if (+z > max_z) maz_z = *z; 
} /* end for «/ 
Maz_depth = max_z + EPS; Min-depth = min_z — EPS; 
/* The EPS helps to avoid a division by zero. */ 


°If z points to the zcoordinate of a vertex stored in coord_pool, z+3 points 
to the zcoordinate of the following vertex. 
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UndoT2(z1, Min-z, SCREEN_SYST); 

UndoT2(z2, Max.z, SCREEN_SYST); 

if (Min_depth < Min-z || Max_depth > Maz.z) { 
Min_depth = Mazimum(z1, Min_depth); 
max_z = Maz.depth = Minimum(z2, Maz_depth); 


} 
Total_.depth = Maz_depth — Min_depth; 
min.z = Maz-depth — 1.25 * Total_depth; 


/* The shade of the vertex depends on the distance from the image plane 
and on the width of the palette. (In our case, we do not use the lowest 
20% of the shades, because then we would hardly be able to see the 
vertices on the black screen.) */ | 


#ifdef HARDWARE_DEPTH.CUING 
G_depthcuing( TRUE); 
G_depths_for depthcuing(min_z, maz_z); 


#else 
lambda = PAL_SIZE/(maz-_z — min-_z); 
if (drawline == quick_line) 
for (z = &Screen-pool(0|[Z]; z < hi_z; z += 3) 
«cur color++ = (*z — min_z) + lambda; 
else 
for (z = &Screen_pool(0|[Z]; z < hi_z; z += 8) { 
20 = (*z — min_z) * lambda; 
«cur _color++ = (z0< z1) ? z1 : ((20> 22)? 22 : 2z0); 
j 
#tendif 


} /*end fill_color-pool() +/ 


Now we can calculate the average depth of a line with the help of pointer arith- 
metic (compare the following code with the one in draw_wireframe() at the 
beginning of this section): 


T, 
void draw_depthcued_wire frame() (— Proto.h) 


{ /* begin draw-_depthcued_wireframe() */ 
register Vector *vl, *v2; /* Pointer into Coord_pool. */ 
register Vector «ptr, *hi_ptr; /* Pointer into Edge_pool. */ 
register short shade; 
Polyhedron +0bj = Object_pool, *hi_obj = obj + Total_objects; 
short *cur_pal; 
calc_rot_matriz(SCREEN_SYST); 


fill_screen_pool(); 
fill_color_pool(); 
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for (; obj < hi_obj; obj++) { 
hi_ptr = (ptr = obj edges) + 2 * obj >no_of _edges; 
cur_pal = Map-color|obj + color index]; 
#ifdef HARDWARE_DEPTH_CUING 
G_colors_for_depth_cuing(cur-pal[0|, cur-pal[PAL_SIZE — 1}); 
#endif 
while (ptr < hi_ptr)) { 
vl = Screen_coords(*ptr++); 
v2 = Screen_coords(*ptr++); 
#ifdef HARDWARE_DEPTH_CUING 
/* Average shade value of line. */ 
shade = (Color_pool|[v1 — Screen_pool] + 
Color_pool|v2 — Screen_pool] + 1) >> 1;7° 
G_set_color(cur-pal|shade}); 
#endif 
draw_line(*v1, *v2); 
} /* end while (ptr < hi_ptr)) */ 
} /* end for (obj...) */ 
}  /* end draw_depthcued_wire frame() */ 


We have mentioned above that wireframes can be manipulated (rotated and 
translated, zoomed, etc.) quickly. Here is one way of manipulating a scene inter- 
actively by means of the keyboard. 


#define ESCAPE (Ubyte) 27 (— Macros.h) 


Global Init_fptr(display_scene, draw_wire frame); (— Proto.h) 
/* When certain keys (e.g., the s-key for “shade” or the h-key for “hidden 
lines”) are pressed, the pointer will point to other functions. */ 


void manipulate_scene() (— Proto.h) 
{ /* begin manipulate_scene() */ 
Ubyte key; 
static Vector delta = { 0.05, 0.05, 0.05 }; 
static float lambda = 1.03; 
while ((key = G_key_pressed()) != ESCAPE) { 
if (key) continue; 
switch (key) { 


/* Change azimuth angle, elevation angle, twist angle. +/ 


10Usually, the shift operator works much faster than an ordinary division. If 
you shift an integer value to the right by 1, this is equivalent to dividing it by 2. 
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case ’a’: Azim[SCREEN_SYST] += delta|0]; break; 
case ’A’: Azim|SCREEN_SYST| —= delta(0|; break; 
case ’e’: Elev[SCREEN_SYST] += delta|1]; break; 
case ’E’: Elev[SCREEN_SYST]| —= delta|1]; break; 
case ’t’: Twist += delta|2]; break; 

case ’T’: Twist —= delta|2]; break; 


/* Change distance and scale factor. +/ 


case ’d’: Dist] SCREEN_SYST] *= lambda; break; 
case ’D’: Dist; SCREEN_SYST] /= lambda; break; 
case ’x’: Scale_factor «= lambda; break; 

case ’X’: Scale_factor /= lambda; break; 


/* Change the draw mode. */ 

case ’w’: 
display_scene = draw_depthcued_wire frame; 
break; 

/* 

case ’s’: display_scene = shade_scene; break; 

case ’h’: display_scene = remove_hidden_lines; break; 

etc. 

*/ 

} /* end switch key */ 
G_clear_screen( BACKGROUND); 

/* Do this before any calculations. In this manner, the processor 
can keep on calculating, while the graphics hardware clears the 
screen, and no time is wasted. */ 

display_scene(); 
G_swap-_screens(); /* Show contents of backscreen. */ 
} /* end while (key != ESCAPE) */ 
}  /* end manipulate_scene() */ 


4.5 Shading 


Of course, wireframes are not very satisfactory. The next step towards realistic 
computer-generated images is to “shade” the facets of our objects. The brightness 
of a face (i.e., the shade in the corresponding color palette) depends on various 
factors. Sophisticated shading models are described in detail in [THAL87] and 
[HEAR86]. In Section 8.8, we will extend the formulas derived in this section. 


For our purposes, we try to simplify the determination of the shade. First let 
us assume that we only have one light source (Figure 3). The shade value s can 
then be calculated in the following three steps: 
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FIGURE 3. The shading of a face (one light source). 


1. According to Lambert’s cosine law (Section 1.2) the amount of light reaching 
the surface depends mainly on the angle of incidence a of the light rays. If the 
light rays are not parallel, their angles of incidence will be slightly different 
for each vertex of the face. In order to keep calculation time within limits, 
we simply take the “average angle of incidence” (i.e., the angle of incidence 
with the barycenter of the face).11 We have maximum brightness when 
the light rays hit the face perpendicularly (a = 0) and minimum brightness 
when the light rays coincide with the plane of the face (a = 7/2). The shade 
value s can be calculated by 


s = reduced_palette | cos (a)|°. (2) 


The value of the variable reduced_palette depends on the amount of “back- 
ground light.” In the pictures in this book, 20% of the total palette size 
are reserved for background or “ambient” light. Therefore, reduced_palette 
comprises 80% of the palette size (0.8* PAL_SIZE), provided that the light 
rays really illuminate the face. “Dark faces” (i.e., faces where the light rays 
fall on the invisible side of the polygon) can be treated in a similar manner. 
There is always a certain amount of light that is reflected from surrounding 
objects and that will illuminate the face. As a rule of thumb, we can say 


111f we deal with large polygons or with polyhedra that approximate smooth 
surfaces, we can also calculate a shade value for each vertex and interpolate the 
shades of the pixels between the vertices (see “Gouraud shading” in Section 4.6). 


112 Chapter 4. Graphics Output 





that this reflected light comes more or less “from the back.” Therefore, the 
brightness of a dark face also depends on the angle of incidence of the light 
rays so that we can again use Formula 2 with a reduced shade value (for 
example: s > 0.338). 





FIGURE 4. The influence of the constant c in Equation 4.2. 


The exponent c has an influence on the appearance of the object (Figure 4). 
For “normal material” (neither mat nor shiny) we let c = 1. For metallic 
material we may set c > 2. /* For mat materials like wood, we let 0.5 < c < 1. 


‘2The use of the constant c like in Equation 2 represents a very rough sim- 
plification of the law of reflection. It will not place highlighted spots exactly 
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Remember that cos(q) is nothing but the dot product of the normalized 
normal vector of the facet and the normalized vector to the light source 
(Section 1.2). In any case, a first approximation of the shade value is 


0 <s < reduced_palette. (3) 


2. A second criterion for the brightness of the face is its (average) distance 
from the light source. 


To increase the speed of the program, we replace the distance from the light 
source by the distance from the base plane of the light system. 





FIGURE 5. When the light source is close to the scene, we have to take into account 
the distance from the light source. 


Let djight be the z-value of the light source in the light system (i.e., the 
distance of the light source from the base plane, see Figure 5), let (Ziight) maz 
be the maximum z-value of the scene in the light system and let Zjignt be 
the average z-value of the face in the light system. The shade value 2 can 

then be modified by 
2 
ose (Ehiate — \eiahtons (4) 

diight — Zlight 
<1 


(The brightness of the face decreases with the square of the distance. ) 


When the light source is far away from the objects, the above-mentioned 
modification is negligible. 


where they ought to be. For smooth reflecting surfaces, it is better to use a more 
sophisticated model, which will be described in Chapter 9 in connection with 
mathematical surfaces and spline curves. 
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FIGURE 6. Additional depth cuing. 


3. A third factor that has an influence on the brightness of the face is its 


distance from the projection center. We can call this factor “additional depth 
cuing.” 

To increase the speed of the program, we replace the distance from the 
projection center by the distance from the projection plane, the latter being 
the z-coordinate in the screen system (see “depth cuing” in Section 4.4). 


Let ambient be PAL_SIZE —reduced_palette, let 2) be the average distance 
of the face from the projection plane (Figure 6), let (zo)min be the minimum 
z-coordinate of the scene in the screen system and let total_.depth be the 
depth of the scene in the screen system. Finally, the shade value is 


“0 — (20) min ( 5) 


bient 
ee ee aun total_depth 
EES, gasaensemas” 





<1 
Now we have 
0<s< PAL_SIZE, (6) 
which means that we use the whole palette. 
Now let us introduce n different light sources. Let I}, Io,...,In be their 


intensities’? and let the n shade values of a face, corresponding to each indi- 


8TIn our simplified model, the colors of the light sources are all white. 
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vidual light source, be 81, 89,...,8n. (The additional depth cuing (5) must not 
be introduced yet.) Then we have 


Stotal = 1,813 + leset+...+ In Sn. (7) 


The value Sota; Should still fulfill Equation 3. This can easily be achieved by the 
condition I, < 1/n, k = 1,...,n. Such astrong restriction, however, implies that 
Stotal is unlikely to ever reach its theoretical maximum value reduced_palette and 
that we will lose parts of the color palette. On the other hand, if Itotai is too 
large, this may sometimes cause the shade value to exceed its maximum. 


If we want to produce an optimum image of the scene, we have to precalculate the 
shade values Siotqi for all the facets and to determine their maximum value S maz. 
If we now scale all the light intensities by the factor \ = reduced_palette/smaz 
(I, — AI,), we can be sure that s¢o¢q; will indeed fulfill condition (3). Finally, 
we modify s; 4a, by additional depth cuing (5). Thus, the entire palette size will 
be used for the shade values. But be careful: once you animate the scene and 
recalculate the light intensities for each frame, the movie will flicker. Therefore, 
it is better not to change the intensities for each frame and to take the risk that 
from time to time a shade value may exceed the palette (take the maximum 
value in that case). 


To put the theory into practice, let us now have a look at a function 
calc_shade_of -face(). 


Bool Solid; (— Globals.h) 

/* This variable indicates whether the object the face belongs to is solid. */ 
float Intensity| MAX_SYST}; (— Globals.-h) 
float Full.width| MAX_SYST], Half_-width| MAX_SYST}; (— Globals.h) 


/* Default values for the intensities of the light sources may be 
for (syst = 1; syst < Total_systems; syst++) 
Intensity|syst| = 1/sgqrt((double ) No-of_lights); 
(Other values 0 < Intensity|syst] < 1 can be read from the data file.) 
The variables Full_width, Half.width are initialized by 
#define AMBIENT (PAL-_SIZE/5) (—> Macros.h) 
#define REDUCED_PAL (PAL_SIZE - AMBIENT) (—> Macros.h) 


for (syst = 1; syst < Total_systems; syst++) { 
Full. width[syst] = REDUCED_PAL + Intensity|syst}; 
Half.width|syst] = 0.5 * Full_width|syst|; 


*/ 
/* We add two members to struct Face. */ 


Ubyte darkface[ MAX_SYST}; 
Ubyte shade[ MA X_SYST}; 
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#define Backface(f) (f > darkface[ SCREEN_SYST}) (—> Macros.h) 
#define Backlit(f, syst) (f >darkface[syst]) (— Macros.h) 
float Average_z; (— Globals.h) 
Bool Init(Smooth_shading, FALSE); (— Globals.h) 
/* In the case of smooth shading Dim must equal 3. */ 
Ubyte Cur_shade; (— Globals.h) 
Ubyte Shade_of.vertex| MAX_POLY_SIZE); (—> Globals.h) 
/* For smooth shading (Section 4.6). */ 
float shade(f, syst) (—> Proto.h) 
Face +f; 
short syst; 


{ /x begin shade() */ 
register float cosine, 3; 
Vector light_ray; 


/* Lambert’s law. */ 
Subt_vec(light_ray, +f —>barycenter, Proj_center|syst]); 
cosine = Dot_product( f normal, light-ray) /Length(light-ray); 
if (Solid) { 
if (cosine > 0) { 
s= cosine * Full_width[syst}; 
Backlit(f, syst) = FALSE; 
}else { 
s= —Half_width|syst| * cosine; 
Backlit(f, syst) = TRUE; 
} /* end if (cosine > 0) */ 
} else { /* Light source and eye on the same side of the plane? */ 
if (cosine «(0.5 — Backface(f)) > 0) { 
if (cosine < ()) cosine = —cosine; 
s= cosine * Full_width[syst]; 
Backlit(f, syst) = FALSE; 
}else { 
if (cosine < 0) cosine = —cosine; 
s= cosine * Half -width|syst}; 
Backlit(f, syst) = TRUE; 
} /* end if (cosine...) */ 
} /* end if (Solid) «/ 
return 5s; 
} /* end shade() */ 


4.6 
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#define Z_in_screen(z, p (—> Macros.h) 
Dot_product(InvRot|SCREEN_SYST|[2], *p)14 

void calc_shade_of _face(f) (— Proto.h) 
Face + f; 


{ /* begin calc_shade_of _face() */ 
register short syst; 
float s; 
register float s0; 


/* z-component for additional depth cuing. +/ 
Z -in_screen( Average.z, *f—>barycenter); 
s0 = AMBIENT x (Average.z— Min_depth) / Total_depth + 0.5; 
for (syst = 1; syst < Total_systems; syst++) { 

sO += (s= shade(f, syst)); 

f—>shade[syst] = s + 0.5; /* Round value. +/ 
} /* end for (syst) */ 
f—>shade[SCREEN_SYST| = Cur_shade = s0 = 

Minimum(s0 + 0.5, PAL_SIZE — 1); 

if (Smooth_shading) { 


Vector #u = f—vertices; 

short 1 = 0; 

float z; 

for (; i < f—>noof_vertices; i++, v++) 
Z-in_screen(z, *v), z —= Average.z, 


Shade_of _vertez|i] = s0 + AMBIENT + (z/Total_depth); 
} /* end if (Smooth_shading) */ 
} /* end calc_shade_of _face() */ 


Basic Graphics Output Algorithms 


The Bresenham Algorithm for the Drawing of a Line 


The most elementary feature a graphics programmer needs is the computer’s 
ability to draw a line by plotting pixels on the screen. Any compiler that supports 
graphics output will also permit the drawing of a line on the screen. What it 
might not support is the drawing of a “rubber band” (also called an “XOR line”). 
For this reason, we will list a function that sets the desired pixels in a very quick 
manner because it only works with integer variables: 


14Since InvRot is a global variable, InvRot]|SCREEN_SYST\[2] is a constant 
address, which is evaluated during the compilation. 
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eT Te 
void plotline(p, q) (— Proto.h) 
Vector! p, q; 
{ /x* begin plotline() */ 
register short 2x1 = p(X], yl =p[Y], 22 = q[X], y2 =alY]; 
short mod, dx, dy, sgn_dy, temp; 


if (21 — 22) 

Swap(r1, 22), Swap(yl, y2); 
dx = 22 -721; 
if (y2 — yl) 

dy = y2 —yl, sgndy = 1, 
else 

dy = yl —y2, sgndy = -1; 


if (dy <= dz) 
for (mod = —((dz+1) > 1); ; 21++, mod += dy) { 
if (mod >= 0) 
yl += sgn.dy, mod —= dz; 
G_set_pixel(x1, y1); 
if (cl == 22) 
return ; 
} /*x end for (mod...) */ 
else 
for (mod = —((dy+1) >> 1); ; yl += sgn.dy, mod += da) { 
if (mod >= 0) — 
xz1++, mod —= dy; 
G_set_pixel(x1, y1); 
if (yl == y2) 
return ; 
} /* end for (mod...) */ 
}  /« end plotline() */ 


‘Rubber Bands’ 


A function rubber_band() has almost the same code as the function plottine(). 
We only have to replace the macro G_set_pizel() by the following macro: 
#-define Set_zor_pizel(x, y)\ (— Macros.h) 
temp = G-get_pixzel_color(x, y),\ 
Cur-color “= temp, \ 


G_set_pizel(x, y),\ 
Cur-color “= temp 


15With this function it does not make any difference whether p and q are of 
the type Vector2 or of the type Vector. Both types are interpreted as pointers 
to a float and only the first two elements of the array are used. 
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The color of a pixel on the line now depends on the color the pixel had before. 
The two colors are connected by the XOR-assign, a fast bitwise operation that 
is undone if we apply it twice. Thus, if we write 


rubber_band(p, q); 


rubber_band(p, q); 


the line is erased and the original background pixel is restored. 


A Fill Algorithm for Convex Polygons 


The task of filling polygons is one of the oldest in computer graphics, which is 
why many people have already solved the problem in various manners. We want 
to give the listing of an algorithm of our own for several reasons. 


e Not all C compilers provide a function that fills polygons the way we need 
it. The so-called “floodfill”-command, for example, which needs a point in 
the interior of a closed area that is defined by a specific color, is not always 
able to fill polygons correctly for our purposes. (We want to erase other 
polygons. Therefore, parts of the interior of the polygon will usually have 
been filled with several colors before.) — 


e Imagine a face of our scene that is comparatively large (for example, the 
base plane of the scene). If we fill the image polygon of the face with one 
and the same color, it will look rather unrealistic. In such a case, we can 
fill our polygon line by line with slightly different colors (mainly according 
to the depth of the points in the screen system) in order to get the impres- 
sion of smooth shading. This method is a special case of Gouraud shading 
({GOUR71)). 


e We will need a fill algorithm for polygons in a slightly modified form in 
Section 6.6, where we talk about transparency. 


e The algorithm is essential for the so-called “depth buffering” and “shadow 
buffering” (Chapter 7). 


Usually, a polygon is drawn by our function fill_poly(). This function works with 
the macros G_move_area(v), G_draw_area(v) and G-_close-area(). If the com- 
piler does not support polygon filling routines, or if we want to do smooth shading 
or “depth buffering,” the macros may call the following functions poly_-move(), 
poly_draw() and poly_close(): 


typedef struct { 
short x, y; /* Pixel coordinates. */ 
float x0; /x For more accuracy. */ 


120 Chapter 4. Graphics Output 


float z; /* For depth buffering. «/ 
float shade; /* For smooth shading. */ 
short prev, next; /* Indices of neighboring vertices. */ 
} Vertex;} (— Types.h) 
Vertex Viz|[MAX_POLY _SIZE); (— Globals.h) 
/* Space for the vertices. This is especially necessary when the polygon has 
to be clipped before it is drawn. */ 
Vertex *Cur_viz, *Min_vtz, *Maz-_vtz; (— Globals.h) 
/* Cur-_vtz points to the current vertex, Min_vtx and Maz-vtz indicate the 
vertices with the minimum and the maximum y—values, respectively. */ 


void poly_move(a) (— Proto.h) 
Vector a; 

{ /« begin poly-move() */ 
Cur_viz = Minvtz = Mazrovtz = Vt; 
Curviz>x = (Cur_viz—>20 = a[X]) + 0.5; 


Cur-vtz>y = alY] + 0.5; 
if (Dim == 3) Cur_vitr—>z = alZ]; 
Cur_vtz++; 


}  /* end poly_-move() */ 


void poly_draw(a) (— Proto.h) 
Vector a; 


{ /* begin poly-draw() */ 
register short *z = &Curviz—>z, ty = x + 1; 


4x = (Curvtz—>x0 = a[X]) + 0.5; ey = alY] + 0.5; 

/* The following question helps to avoid “double points” on a polygon (since 
the coordinates are round, this may happen even when the vertices are 
different). + / 

if (#2 == (Curvtz —1)>2 && ty == (Curviz - 1) >y) 
return ; 

if (ty < Minvtrz—>y) 

Minwvtz = Cur-_vtz; 

else if (ty > Maz_vitz—>y) 
Mazvtz = Cur-_vtz; 

if (Dim == 3) Cur_vtz—>z = alZ]; 

Cur_vtz++; | 

}  /* end poly_draw() */ 


*®Tt is also possible to use the type Ubyte for the shade. In this case, however, 
sizeof(Vertex) will be 15 instead of 16. The program runs faster when the size 
of the structure can be divided by 4. 
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void poly_close() (— Proto.h) 


/* begin poly.close() */ 
register short i, size; 


size = Curvtz — Viz; 

if (size <= 1) { 
G_set_pirel(Vtz->2, Vtr—>y); 
return ; 


_ /* Now all the vertices are concatenated. +/ 
for (t= 0; i< size; i++) 
Viz[i].prev = i—1, Vtzli].next = i+ 1; 
Vtz[0|.prev = ——size; 
Vtz|size|.next = 0; 
flush.poly(); /* The actual fill routine. «/ 
}  /* end poly_close() */ 





FIGURE 7. How to fill a polygon by splitting it into trapezoids. 


The actual filling of the polygon is done by the function flush_poly(). This 
function splits the polygons into triangles and trapezoids with z-parallel sides. 
Figure 7 shows that, in general, each trapezoid will have two new (temporary) 
vertices. 


id flush_poly() (— Proto.h) 


vo 
{ /* begin flush_poly() */ 
register Vertex + al, *a2, *bl, «b2; 
static Vertex reserve[2]; /* The temporary vertices. «/ 
Vertex *r = reserve; 
short i; 
float t; 
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al = b1 = a2 = 02 = Minvtz; 
for (; a2!= Maz-_vtz || b2!= Maz-_vtz; al = a2, bl = 62) { 
while (a2! = Maz-vtz) { /x Next Ag with greater y. */ 
a2 = Vtx + al—prev; 
if (aly == a2>y) 
al = a2; 
else break; 

} /* end while «/ 

while (62! = Maz-vtz) { /* Next Bo with greater y. */ 
b2 = Vtx + bl—nezt; 
if (bly == b2>y) 

b1 = 062; 
else break; 

} /* end while +/ 

if (a2Q>y > b2—y) { /* Interpolate new Ap. */ 

t = ((float) b62>y—-al—y)) /(a2—>y—- aly); 
r>z0= al—->z0 +t*(a2—>20 —al—z0); 
r>y = b2>y; r>prev = a2 —Vtz; a2 = 7; 
r++; 

}else if (a2—>y < 62—y) { /* Interpolate new Bo. */ 
t = ((float) a2>y —bl—>y)) /(b2—y — bly); 
r>2x0= bl1>20+t*(b2>20 — b1-—>20); 
r>y = a2—>y; r>nert = b2 — Viz; b2 = 71; 
r++} 

} /x end if (a2—>y) */ 

filltrapezoid(al, 61, a2, 62); 

if (r—reserve > 2) 
r= reserve; 


} /* end for (a2...) */ 
} /x end flush_poly() */ 


Here is a code for the filling of a trapezoid: 


void filltrapezoid(al, 61, a2, 62) (— Proto.h) 
Vertex *al, *b1, *a2, *b2; 

{ /« begin fill_trapezoid() */ 
register float 71, x2, dzrl1, dz2; 
short y, ymaz, dy; 


y = al>y, ymaz = a2d->y, dy = ymaz —-y; 
if (dy == 0) return ; 
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/* Increments on the lines A,B, and A2Bo. */ 

zl = al—z0; x2 = 6b1—20; 

dx1 = (a2>2z0 — 21) /dy; dx2 = (b2—>20 — 22) /dy; 
/* To round off the coordinates. */ 

if (cl < 22 || a2—>2x0 < 62—20) 


z2 += 0.5; 
else 
xr1 += 0.5; 


if (Dim == 2) { 
for (; y< ymaz; yt++, 21+=drl, 12 += dz2) 
G_move_xry(21, y), G_draw_ry(2z2, y); 
return ; 
} /* end if (Dim == 2) */ 
} /* end filltrapezoid() */ 


Smooth Shading (Gouraud Shading) 


With a computer that is able to display palettes with many different shades, the 
objects (especially polygonized surfaces) can be shaded by means of Gouraud 
shading [GOUR71]. In the case of curved surfaces, this may even save time (in 
spite of the fact that the fill algorithm slows down the program), because we 
need much fewer polygons on the approximating polyhedron. 


At the end of fill-trapezoid(), we add the lines 


if (Smooth_shading) { 
float sl, s2, dsl, ds2; 
short *p = Map-color|Cur_palette|; 


sl = p|(short ) al—>shade] + 0.5; 
s2 = p|(short ) b1—> shade] + 0.5, 
ds1 = (pla2—> shade] — s1) /dy; 
ds2 = (plb2—> shade] — s2) /dy; 
for (; y < ymaz; y++, 
x1 += drl, 22 += dr2, sl += dsl, s2+= ds2) 
if (cl <= 22) 
shade_scan_line((short) 21, (short ) 22, y, s1, s2); 
else 
shade_scan_line((short) £2, (short ) 21, y, s2, s1); 
} /* end if (Smooth_shading) «/ 


The routine shade_scan_line() may look like this: 
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void shade_scan_line(r1, 22, y, 31, $2) (— Proto.h) 
register short 21, 22, y; 
float 31, $2; 


{ /* begin shade_scan_line() */ 
float ds = s2 — sl; 
static short j, dz, sign.s, k; 


if (cl >= 22) 
return ; 
if (fabs(ds) < 0.5) { 
G_set_color(s1); 
G_move_xry(x1, y); G_draw_xry(x2, y); 
return ; 
} /* end if (ds) */ 
if (ds < 0) 
ds = —ds, sign.s = -—l; 
else 
sign_s = 1; 
dx = 22 —21;k = 1; 
G_set_color(s1); G-move-_zy(x1, y); 
for (j = —(dz >> 1); 21 <= 22; a1++, j += ds) { 
if (j >= 0) { 
G_draw-zy(zl, y); 
if (c1 == 22) 
return ; 
if (+ +k == ds) { 
G_set_color(s2); G_draw_ry(x2, y); 


return ; 
}  /* end if (k) «/ 
j —= dz, s1 += signs, G_set_color(s1); 


} /* end if (j) */ 
} /* end for (j) */ 
Gdraw_ry(x2, y); 
} /* end shade_scan_line() */ 


5 
A Fast Hidden-Surface Algorithm 


Ever since the beginnings of computer graphics, many algorithms have been 
developed to remove those parts of the image of a scene that are obscured by 
other parts, and yet none of these algorithms seems to be entirely satisfactory. 
Among the general working algorithms, we have the “scan-line” algorithms, the 
“area subdivision” algorithms, “z-buffering,” “ray tracing” and many others. If 
you want to read more about these algorithms, please refer to the following 
sources: [SUTH74/2], [THAL87], [GLAS90]. 


In this chapter we will talk about a rendering algorithm that in fact is already 
very well known: the “painter’s algorithm,” also called the depth sort or priority 
algorithm. It processes polygons in a similar way as a painter might do it. The 
images of distant polygons are painted first, to be obscured partly or completely 
later on when the images of those polygons are painted that are closer to the 
viewer. The problem is to put the polygons into an order according to their 
priority. 


This algorithm is extremely fast in removing hidden surfaces, but it has three 
enormous disadvantages. 


e It is not a general algorithm — given an arbitrary set of polygons, it may 
happen that we cannot find a correct priority list. Especially when we deal 
with the intersection of objects, we have to split them up in a certain way. 


e If we consider each polygon as an object in its own right, the calculation 
time for the priority tests will increase dramatically for scenes that consist 
of hundreds or thousands of polygons. 
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e The painter’s algorithm only works on the screen and is not suitable for 
plotter drawings. 


This may be the reason why many books on 3D-graphics mention the painter’s 
algorithm only briefly and then go on to more general and more sophisticated 
rendering methods. 


In this chapter, however, we will see that the painter’s algorithm can be applied 
very effectively to almost any kind of scene (even if it has thousands of faces and 
intersecting objects) and to create PostScript images. Of course, this does not 
mean that it can replace all the other rendering algorithms, but it can be used 
as a powerful tool for 


e the manipulation of rendered scenes on the screen. 
e the fast creation of movies. 


e the efficient creation of PostScript-images.' 





FIGURE 1. Priority determination with the help of separating planes. 
The secret of fast rendering is twofold: 


1. We polygonize more complicated polyhedra in a special manner (for exam- 
ple, we cut them into “slices” ). 


*Polygons that are painted in PostScript-mode on a laser printer will erase 
previously painted polygons. 


O.1 
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2. We combine as many polygons as possible to primitives of different levels 
(this may be a “ring” or a “ribbon,” a “slice,” an “object” (polyhedron) or 
even an “object group”). In [NEWM84], such accumulations of polygons are 
called “clusters.” 

These primitives can be separated by planes: 


A “separating plane” o divides the space into two halfspaces (Figure 1). The 
plane o itself may belong to both halfspaces. If we now have two primitives 
A and B, each of which is completely inside of one of the halfspaces (like two 
neighboring slices of a polyhedron), the priority between A and B can be 
determined quickly. If A is not inside the same halfspace as the projection 
center, it can never obscure B. Therefore, it will always be correct to draw 
the image of A before the image of B.” 


The idea of the painter’s algorithm can also be applied to the plotting of cast 
shadows. We can even introduce transparent objects and reflections (Chapter 6) 
without any major loss of speed. 


For really complicated scenes or objects, which can neither be subdivided easily 
nor polygonized in the way we need it, we can still use other rendering algo- 
rithms (in Chapter 7 we will have a closer look at the above-mentioned “depth 
buffering,” which will be extended to a “shadow buffering” ). 


Objects with Convex Outlines 


The most convenient objects by far are convex polyhedra. They have a convex 
outline, which is the image of the spatial contour polygon, for every projection. 
This is still true when we subtract some faces from a convex polyhedron (Fig- 
ure 2). In many cases, the “object preprocessor” described in Chapter 3 will 
provide the computer with an object list where the non-convex polyhedra are 
split into convex parts. 


Convex polyhedra are characterized by the fact that each face is either an in- 
visible “backface” or a “frontface” that is not obscured by any other face of the 
same polyhedron. We can say that the face of a convex polyhedron is locally 
either completely visible or completely invisible. The criterion for the removal 
of the backfaces is very simple. The normal vector, which is oriented towards 
the outside of the polyhedron, includes an angle a with the vector from an arbi- 
trary vertex of the face to the projection center. If |a| < 1/2, the face is visible, 
otherwise it is not. 


Thus, we can render a convex polyhedron by ignoring the backfaces and by 
plotting all of the frontfaces in an arbitrary order. Furthermore, every (non- 


*The negation of this statement is: it may be wrong to plot B before A (if 
the images of A and B do not overlap, the drawing order is of no importance). 
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solid) polyhedron with a convex outline can be displayed in two steps: first we 
render all the backfaces and then the rest of the faces. 


FIGURE 2. Polyhedra with convex outlines. 


To determine the type of a face, we use the function 


wean oe) tee le!!!™~*~<;CSO ee 
void face_types(obj, syst) (— Proto.h) 
Polyhedron * 0bj; 
short syst; 
{ /* begin face_types() */ 
Vector proj-_ray; 
register Face +f = obj— faces; 
register Vector «center = (Vector *) Proj_center(syst]; 
Face *hi_f = f+ obj—>no_of _faces; 


for (; f < hi-f; f++){ 
Subt_vec(proj_ray, *f—>vertices(0], *center); 
f >dark face|syst]| = (Dot-product(f—>normal, proj-ray) <= 0); 
} /* end for (f) */ 
} /* end face_types() «/ 


The corresponding C code to plot a convex polyhedron looks like this: 


O.2 
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TT. | 
void plot.convex_polyhedron(obj) (— Proto.h) 


Polyhedron *obj; 


{ /« begin plot_convex_polyhedron() */ 
register Face + f, *hi_f; 


face.types(obj, SCREEN_SYST); 
hi.f = (f = obj >faces) + obj ~>no-of -faces; 
for (; f < hi-f; f++) 
if ('Backface(f)) plot_face(f); 
} /* end plot_convex_polyhedron() */ 


Th.) pT 
void plot.polyhedron_with_convex_outline(obj) (— Proto.h) 


Polyhedron +*ob7; 


{ /« begin plot_polyhedron_with_convex_outline() */ 
register Face * f, *hi_f; 


facetypes(obj, SCREEN_SYST); 

hi_f = obj > faces + obj >no_of _faces; 

for (f = obj > faces; f < hi_f; f++) 
if (Back face(f)) plot_face(f); 

for (f = obj—> faces; f < hi_f; f++) 


if ('Backface(f)) plot_face(f); 
} /* end plot_polyhedron_with.convex_outline() */ 


Surfaces of Revolution 


We have already seen that convex polyhedra have some unique properties that 
can be used successfully. The same is true for another family of polyhedra ®. In 
the following, we will simply call them “surfaces of revolution,” but it should be 
kept in mind that they are, in fact, only approximations to surfaces of revolution. 


Figure 3 shows how we have to plot the surface. Let us assume that the object 
preprocessor has “sliced” the polyhedron ® and that the normals of the faces 
are oriented correctly (Section 3.6). Then each “slice” of © consists of one or 
more “rings” and we can render the slice as follows: from the outermost ring to 
the innermost ring, we plot all the backfaces and then, going from the innermost 
ring to the outermost ring, we plot the remaining frontfaces. 


The only problem is in which order to plot the slices. For this purpose, we 
consider planes o (Figure 3) that are perpendicular to the axis of the surface 
(polyhedron) ® and that separate the slices of ®. Additionally, we introduce a 
special separating plane og that coincides with the projection center. It may or 
may not cross ® so that we distinguish between two different cases. 
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1. oo does not cross the polyhedron ®. Then the rendering is easy: we can 
render one slice after the other, beginning with the slice with the maximum 
distance from oo. 


2. oo crosses ®. Then it splits ® into two polyhedra ; and ®2 (each of which 
is completely in one of the two half spaces defined by oo ) and a “critical 
slice” Lig , consisting of the faces that intersect og. Since og coincides with 
the projection center, its image will be a line s) = 05 , which separates the 
images of ©, and ®2. Therefore, we can plot these images separately like 
in case 1. Only the image of the critical slice will obscure some parts of the 
images of ®, and ®9, and that is why it has to be drawn after the rest. 





FIGURE 3. How to plot a simple “surface of revolution.” 


The rendering algorithm is extremely efficient. The computer will need only a 
short time for the determination of visibility. Thus, we can render and manipulate 
even complicated polyhedra. 
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5.3 Sliced Surfaces 


In the previous section we sorted primitives with the help of separating planes. 
Each pair of neighboring slices of the surface of revolution ® is separated by a 
plane that is normal to the axis of the polyhedron. 


Thus, it should be possible to render even complicated surfaces in an equally 
fast manner, if we are able to polygonize them slice by slice. In [BLOO87], for 
example, such an algorithm is described in detail for polyhedra with known 
implicit equations. 








FIGURE 4. How to render a complicated slice by splitting it into “ribbons.” 


What we still need to know is how to render a general slice. First we determine the 
types of all the faces (backfaces or frontfaces) of the slice and combine adjoining 
faces of the same type to “ribbons” (Figure 4). It should always be possible to 
render the ribbons one after the other in the correct order (from the back to 
the front). The reason for this is that none of the ribbons can contain another 
ribbon (otherwise it would have been split into two ribbons). 


The priorities among the ribbons can be determined as follows. Imagine an axis 
s that is perpendicular to the separating planes o of the slices and that goes 
through the projection center C’. It can be interpreted as the axis of a pencil of 
planes (v). Each ribbon is confined by a sector that is defined by two planes of 
the pencil. For the determination of the priority between two ribbons A; and R;, 
we distinguish between two cases: 


1. The two corresponding sectors do not overlap. Then the priority between 
R, and R; is of no importance. 


2. The sectors overlap. Then both of the rings have a set of vertices inside the 
common sector. For these sets we determine the maximum distances from 
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FIGURE 5. Examples of sliced surfaces. 
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the projection center. The ring with greater maximum distance has to be 
plotted first. 


When we check all the priorities between the ribbons, we can put them into an 
order. Even though this way of sorting seems to be similar to the algorithms 
for the sorting of numbers, it is different. If you sort numbers, the negation of 
nj <n; is, of course, n; > n;. In priority lists, the negation of “R; prior to R;” 
can either be “A; prior to R,;” or “no priority between R; and R;.” (This makes 
the sorting easier. On the other hand, if we have an array of sorted primitives it is 
no longer possible to reconstruct the priorities between them!) This is the reason 
why we occasionally get several priority lists, all of which are correct and which 
depend on the “starting position of the primitives” in the sorting algorithm. 


Now that we know how to plot an individual slice, it is easy to render the whole 
surface. The plotting order of the slices is exactly the same as for the rendering 
of surfaces of revolution (Section 5.2). 


5.4 Function Graphs 





FIGURE 6. A function graph cut into slices that are parallel to the base plane. 


As we mentioned in Section 3.6, function graphfunction graphs play an important 
part in the applied sciences. This is why many authors have dealt with the 
problem of the fast rendering of such surfaces. A frequent method of plotting the 
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images of function graphs is to use the “floating horizon algorithm” ([ROGES85], 
[PLAS86]). However, this algorithm only works under certain conditions. 


Function graphs can be cut into slices that are parallel to the base plane. This is 
a good idea, provided that the domain of definition is not a rectangle (Figure 6). 
It also depends on the kind of graph we want to render. 


Let us assume that the domain of definition is a rectangle so that it is easy to 
slice the graph I by means of the planes o and w, which are normal to the base 
plane @ and parallel to the sides of the base rectangle. Now we will see how we 
can plot the image of the graph slice by slice in the correct order. 


Let oo and % be the two “main normal planes” of the base plane and let them 
coincide with the projection center C (Figure 7). We have to distinguish between 
three different cases: 


1. oo and vy do not intersect the graph I’. Then the image of I’ can be plotted 
as follows: 


The surface is cut into slices which are separated by our planes o. Thus, 
the drawing order for the slices is clear: we plot one slice after the other, 
starting off with the slice that has maximum distance from the plane oo. 
Each slice consists of a number of patches W. These patches are separated 
by our planes ~. Thus, the patches can also be plotted one after the other, 
starting off with the one that has the greatest distance from wo. 


Each patch consists of two triangles, separated by a “diagonal plane” 6, 
which is orthogonal to the base plane . (It is of no importance which of the 
two diagonal planes is chosen. The patch may even consist of more than two 
triangles.) The triangle that is not in the same halfspace as the projection 
center has to be plotted first. 


Since the separating planes co, 7) and 6 appear as straight lines in the nor- 
mal projection on the base plane £, the priority determination is only two- 
dimensional. ‘Therefore, it can be done very fast. 


2. One of the two planes (09 or yo) intersects [. Then I is divided into two 
parts I’; and I, plus a “critical slice” Uo (i.e., the slice that is intersected by 
Oo or wo). The plane acts as a separating plane between I’; and 'g. Because 
its image is a straight line, the images of ['; and [2 will not intersect each 
other and each of the two parts of the graphs can be rendered separately 


like in case 1. At the end, we render Xo. Its image will obscure some parts 
of I; and IT. 


3. The two main normal planes op and wo intersect the graph T. Now [I is 
split into four graphs [; (4 = 1,...,4) plus four critical slices ©; plus a 
critical patch Vo. The images of [; will never overlap because o9 and yo 
are separating planes, the images of which are straight lines. Thus, we can 
render the images of ['; separately like in case 1. Then we render the critical 
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slices L; in an arbitrary order (their images will not overlap either, even 
though they will obscure some parts of the graphs I). Finally, we plot the 
patch Vo, which may obscure some parts of ¥;. 


Oo 








FIGURE 7. How to plot a function graph that is sliced perpendicularly to the base 
plane. 


Priority Among Objects 


Up to now, we have dealt with single polyhedra, which may consist of an arbitrary 
number of faces. In this section, we will learn how to determine the priority 
between two polyhedra (if this is possible). In Section 5.6, we will determine the 
priority lists of several objects. 


Let A and B be two polyhedra that can be separated by a plane co. (This means 
that A and B do not intersect and that neither of them surrounds the other 
one). We want to know which polyhedron has to be plotted first in order to get 
correct visibility. 


For reasons of speed, the priority test will be made in several steps: 


Step 1: Check the bounding rectangles (Figure 8). 


Do the bounding rectangles overlap? If not, it does not matter whether we 
plot A first or B. (This is the easiest priority decision possible and the most 
convenient result for the priority list.) If the bounding rectangles overlap, 
continue with Step 2. 
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FIGURE 8. Bounding rectangles. 


Step 2: Determine the priority by means of depth-comparisons or sep- 


arating planes. 


Is the maximum z2-value of A smaller than the minimum z-value of B so 
that A has to be plotted first? 


If not, it is a good idea to check whether specific spheres that contain the 
objects intersect (Figure 9). Such a “soap bubble” around an object may 
be a sphere with the barycenter of the object M as its center and with the 
greatest distance from M to the vertices as its minimal radius r. The two 
soap bubbles around A and B do not intersect if MaMg > ra+rzp. In this 
case, the priority between A and B is the same as the priority between their 
soap bubbles, which can be determined simply by comparing the depths 
(the z-values in the corresponding systems) of their centers. 





If the soap bubble test does not work because the distance between the 
centers is too small, we try to use a separating plane that divides the space 
into two halfspaces, one of them containing A, the other one containing B 
(Figure 1). The existence of at least one separating plane o is a fundamental 
condition for the use of the painter’s algorithm. (In Section 5.8, we will see 
how we can find a.) The polyhedron that is completely in the halfspace that 
does not contain the projection center has to be plotted first. 


The methods we discussed in Step 2 are very useful for the quick determination 
of priority. They have, however, some disadvantages: 


— Sometimes it is hard to find a separating plane (Section 5.8). 
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FIGURE 9. “Soap bubble test.” 


— When the outlines of the polyhedra do not really intersect (which may occur 
even when the bounding rectangles overlap), the result may be useless for 
the priority list. This means that if the images of A and B do not overlap, 
and if we assign a priority between A and B in spite of that, this may lead 
to a contradiction in the priority list (“Gordian knot” — see Section 5.6). 


— Even though the above-mentioned tests are fast in checking the priority, 
they can produce longer computation times later on (especially when we 
plot shadows). Consider the following (rather common) case: the object A 
is completely obscured by B. The priority test in Step 2 only tells you that 
A has to be plotted first. Therefore, the computer will spend some time 
plotting A, but in the end, the image of A will be erased! 


Thus, in the following three cases, we have to go one step further: 


— We were not able to find a separating plane between A and B. 
— A “Gordian knot” has occurred during a first test. 
— The second object that is to be plotted is solid and may obscure the one 


that is plotted first. 


Step 3: Intersect the outlines (the images of the contour polygon). 


When intersecting the outlines, we have to distinguish between three differ- 
ent cases: 
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a) The outlines 


are disjoint. 


db) One outline contains 


the other one. 


A critical case 


Ol intersection. 


FIGURE 10. Intersection of the outlines of two polyhedra. 


1. The outlines are disjoint (Figure 10a), so that the drawing order of A 


and B is of no importance. 


2. The outlines intersect (Figure 10b). Any of the intersection points in 


the image plane 7can be interpreted as the image of a point P on 
the spatial contour of A or as the image of a point Q on the spatial 
contour of B. The distances of the two space points from the image 
plane x (the z-values in the screen system) may be p, and q,. According 
to the considerations in Section 2.3 (Equation 21), we transform these 
values into 
a Pz * dz 
Pe dp, d-a (1) 


If p} < qz, the object A has to be plotted first, otherwise B has to be 
plotted before A. 


3. The outline of A contains the outline of B or vice versa (Figure 10c). 


If we were not able to make a priority decision in Step 2, this case is 
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a bit inconvenient. (One might think that it is enough to compare the 
z-values of the barycenters of the objects. In most cases this will work, 
and yet there are examples where it won’t.) 

Consider a plane 6 that is determined by the projection center C, an 
arbitrary vertex P on the spatial contour polygon of A and an arbitrary 
vertex Q on the contour polygon of B. This plane will intersect the 
spatial contour of A in a second intersection point P. The line PP 
and the projection ray C'Q both lie on éand they will intersect in a 
point Q. If we compare the z-values g*, g* of Q and Q (modified by 
Equation 21), we can determine the priority (if we have g¥ > g*, the 
image of B has to be plotted first). 

If the outline of the second object that is to be plotted contains the 
outline of the other one and if this obscuring object is convex (and 
therefore, solid), the priority between A and B is of no importance. 
This will simplify the generation of the priority list and, what is more, 
the obscured object does not have to be plotted at all! 


Before we list the code for a C function that returns the priority of two objects 
A and B, we have to give the definition of a “halfspace”: 


#define NOT_FOUND 0 
#define USE.SOAP_BUBBLES 2 


typedef struct { /* Halfspacex / 
Vector normal; /* Normal to defining plane. */ 
float cnst; 


/* Dot product of the normal vector and the position vector of the 
point on the plane. */ 


short info; 


/* This structure member contains some additional information: info = 

NOT_FOUND: The plane was not to be found. 

info = +1: The first of the two objects that are to be compared lies 
on the positive/negative side of the plane. 

info = USE_SOAP_BUBBLES: Do not use the halfspace for priority 
decisions. The distance between the objects is big enough for 
the “soap bubble test” (Figure 9), which — in this case — will 
also be more reliable. 


} Halfspace; (— Types.h) 


Now we extend the definition of a Polyhedron by some additional variables: 


Halfspace *sep_plane; 


/* Separating planes are used as an efficient tool for the determination 
of the priority of two objects when their images overlap. +/ 


short sep_start; 


/* Indicates the first separating plane of the object. +/ 
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float maz_rad; 


/* This variable equals the radius of the smallest possible sphere that 
circumscribes the polyhedron (with the barycenter as its center). +/ 


Vector *bounding-boz; 


/* This array of vectors stores the coordinates of the eight vertices of 
a rectangular box that circumscribes the polyhedron in the world 
system (usually the sides of the box are parallel with the coordinate 
planes, but this does not always have to be the case). */ 


Vector *boz_min, *box_maz; 


/* Every image of an object (polyhedron) has a so-called “bounding 
rectangle,” which is determined by the minimum screen coordinates 
and the maximum screen coordinates. The first two coordinates 
of bor-min|SCREEN_SYST]| and box-maz|SCREEN_SYST] are re- 
served for these values. The z-values equal the minimum and the 
maximum distances from the projection plane in the screen system. 
What we said about the “bounding box” in the screen system is 
also true for bounding boxes in the various light systems. Thus, 
bor_min|LIGHT_SYST 1] and box_maz|LIGHT_SYST 1] store the 
minimum and the maximum values of this box in the first light sys- 
tem, and so forth. */ 


short *size_of contour; 


/* The polyhedron has a (spatial) contour in the screen system and in 
the light systems. The number of the vertices on each contour is 
stored in this array. */ 


Vector ***contour; 


/* Relax. It’s just three stars, that’s all. *contour|k] is an array of point- 
ers to the vertices on the (spatial) contour line of the polyhedron in 
the k-th system (SCREEN_SYST,...). Thus, *(contour[k] + n) is 
the n-th point on the contour line in the same system. */ 


Ubyte obscured[M AX SYSTEMS); 


/* When an object is completely hidden (shadowed) by other objects in 
the k-th system, we let obscured[k] = TRUE. +/ 


Now to the desired function: it can be used for priority tests in the screen system 
as well as in the light systems. (Priority in a light system means: does A cast a 
shadow on B, or B cast a shadow on A, or do neither of them cast shadows’) 


#-define NOT.FOUND 0 (— Macros.h) 
#-define USE.SOAP_BUBBLES 2 (— Macros.h) 
#-define NONE MAX _UBYTE (— Macros.h) 
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#define Is_closer(obj) {\ (local macro) 
first = obj >indez; \ 
if (critical) goto intersect_outlines; \? 
else return first; \ 


} 

#define DISJOINT 1 (— Macros.h) 
#-define INTERSECTION 2 (— Macros.h) 
#define POLY2INSIDE_POLY1 3 (— Macros.h) 
#define POLY1INSIDE_POLY2 4 (— Macros.h) 


| 
Ubyte which_obj_is_first(obj1, 0bj2, syst, critical) (— Proto.h) 
register Polyhedron *o0bj1, *0b72; 
short syst; /x Screen system or light systems. */ 
Bool critical; /x Without or with separating planes. */ 


{ /«* begin which_obj_is_first() */ 
register Vector * minl, *mazl, *min2, *maz2; 
float z[2); 
Halfspace * sep_plane; 
Ubyte first = NONE; 


if (0bj1->obscured[syst] || 0bj2—>obscured|syst]) 
return NONE; 
/* Do the bounding rectangles overlap? */ 
minl = obj1—boxr_min + syst; marl = obj1—>bor_mar + syst; 
min2 = obj2—boxr_min + syst; maz2 = 0bj2—>bor_mazr + syst; 


if (!overlap(min1, mazx1, min2, maz2)) 
return NONE; /* Bounding rectangles do not overlap! */ 


if ((*min1)[Z] > (*maz2)|Z]) 
{ Is.closer(obj1); } 

else if ((*min2)[Z] > (*maz1)[Z]) 
{ Is.closer(obj2); } 


/* Next step: try with separating planes. +/ 


3The use of statement labels is generally frowned upon in high-level program- 
ming languages because they make programs hard to maintain. Of course, one 
does not have to use them. Sometimes, however, it is both easier and faster to use 
the goto-statement because it can help to avoid a lot of conditional branching 


in a routine. 
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sep-plane = obj71—>sep_plane + 0bj2—>indez; 
if (sep_plane—>info == USE_SOAP_BUBBLES) { 
if (average_dist(obj1, syst) < average-dist(obj2, syst)) 
{ Is.closer(obj1); } 
else 
{ Is.closer(obj2); } 
} else if (sep_plane— > side! = NOT_FOUN A { 
if (Which_side(Proj-_center[syst], *sep_plane) == sep_plane—> info) 
{ Is_closer(obj1); } 


else 
{ Is.closer(obj2); 
} /* end if (sep_plane) * 


/* Final decision: we intersect the convex hulls and compare the z-values of 
the two space points that correspond to the first intersection point. */ 


inter sect_outlines : 


switch (relative_pos_of _hulls(z, 
0bj 1 —> size_of _contour|syst], obj1—>contour|syst], 
0bj2-> size_of -contour|syst], 0bj2—>contour|syst], syst)) { 
case INTERSECTION : /* Take the nearest point. */ 
if (z[0] > 2[(1]) return obj1—>indez; 
else return 0bj2—>indez; 
case POLY2_INSIDE_POLY1: 
if (first == obj1—index && Is_convex(obj1)) { 
0bj2—>obscured|syst] = TRUE; 
if (syst == SCREEN_SYST) 
return NONE; 
else return first; 


if (first == NONE) { 
if (point_behind_polygon) return obj1—>indez; 
else return 0bj2—indez; 


return first; 
case POLY 1_INSIDE_POLY2: 
if (first == obj2—>inder && Is_convex(obj2)) { 
obj 11—>obscured|syst] = TRUE; 
if (syst == SCREEN_SY ST) 
return NONE; 
else return first; 
} /* end if (first) «/ 
if (first == NONE) { 
if (point_behind_polygon) return o0bj2—>indez; 
else return obj1—>indez; 
} /* end if (first) */ 
return first; 
case DISJOINT : 
return NONE; 
} /* end switch() */ 


} /* end which_obj_is_first() «/ 
Jb frend whichobj-is-first() +f 


0.6 
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| , | 
Bool overlap(min1, max1, min2, maz2) (— Proto.h) 
register Vector * minl, *mazl, *min2, *maz2; 


{ /* begin overlap() */ 
if ((xmin1)|X] > (*max2)[X] || (xmaxl1)[X] < (*min2)[X] || 
(*min1)[Y] > (*mazx2)[Y] || (#max1)[Y] < (*min2)[Y]) 
return FALSE; 
else return TRUE; 
}  /* end overlap() */ 


float average_dist(obj, syst) (— Proto.h) 
Polyhedron « 0b); 
short syst; 


{ /* begin average_dist() */ 
Vector r; 


Subt_vec(r, *0bj > barycenter, Proj_center[syst]); 
return Dotproduct(r, r); /* We do not need the sqrt(). */ 
}  /* end average_dist() */ 


Final Priority List 


In Section 5.3, we developed a sorting algorithm for “ribbons.” This algorithm 
can also be used for the sorting of objects. First we determine the priorities among 
our n objects with the indices 0,...,n—1, which takes n(n) comparisons. Our 
goal is now to create a list order[0..n — 1], in which we store the indices of the 
objects in the same order in which they have to be plotted. This list need not 
be unequivocal. 


To create the list quickly, we start the recursive “mikado algorithm” ,4 which 
resolves the scene in quite a natural manner. We select those k objects that are 
not obscured by any other objects (the “front objects”) and add them at the end 
of our list. Now the number of objects to be sorted is reduced to 7 = n — k. If it 
is impossible to select an object, we have a “Gordian knot” and priority sorting 
is impossible, too. In such a case, we have to split up some of the critical objects. 
If sorting is possible, we lower the end of the list to order[n]. Among the residual 


“Named after the “Mikado” game: several dozens of thin, painted sticks are 
thrown in a random pile on a table. The players have to pick up as many sticks 
as possible without moving any of the other sticks. 
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objects, we will again find objects that are not obscured by any other residual 
objects. Their indices have to be put at the lowered end of the priority list, etc. 
The algorithm is repeated until no more objects are to be sorted. 


The mikado algorithm can be accelerated when we apply it twice (from the front 
and from the back): 
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FIGURE 11. When we try to solve the “mikado”-puzzle we first remove the sticks 
that have no influence on the scene. Thus, we simplify the scene in a similar manner 
as the “mikado algorithm.” 


We select the k; front objects that are not obscured by any other objects. As 
usual, we place these objects at the end of our priority list. Furthermore, we pick 
those kz objects that do not obscure any other objects. These “back objects” 
come first on the list. Now there are only 7m = n — k, — kp residual objects to 
be sorted. The recursion is finished when no more residual objects are to be 
sorted. It has to be stopped when no front objects or back objects can be found 
among the residual objects. In this case, we get a certain number of objects with 
a, Gordian knot. (Imagine a scene of 50 objects where sorting is impossible just 
because three of the objects form a Gordian knot. The mikado algorithm will 
most probably stop when we only have a few residual objects, among which are 
the critical ones. Thus, it will be easy to isolate the critical objects and to split 
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them. A message like “Cannot sort your 50 objects — try to split the scene!” 
would not be very helpful... ) 


A pseudo-code of the algorithm may look like this: 


Determine priorities among the n given objects 


Residual objects := given objects 
tmin := 0,i-mazxr := n 
repeat 


select kj front objects and kz back objects among residual objects 
ifk,; >0 A ke >0 
store indices of front objects at 
order|i.max — ko]... order[i-maz — 1] 
store indices of back objects at 
order|i_min]...order|i_min + k, — 1] 


imin := tmin+k, 
imax := i.maz — ko 
residual objects := residual objects minus 
front objects minus back objects 
else 
error message "Gordian knot" 
endif 


until no more residual objects V Gordian knot 


Before we can do the sorting, we have to determine all the priorities among the 
objects. The function priorities() is written in a flexible manner so that it can 
be used for different systems (screen system, light systems) and for arbitrary sets 
of objects (e.g., object groups). 


| 
void priorities(n, given_obj, syst, critical) (— Proto.h) 
short. n; /* Number of objects. */ 
Polyhedron *given_obj| |; /* Array of pointers to objects. */ 
short syst; /* Screen system, light systems. */ 
Bool critical; /* Can we rely on separating planes? */ 
{ /* begin priorities() */ 
register Polyhedron **obj1, **0bj2; 
Polyhedron +**hi_obj = given_obj + n; 
register Ubyte +pr1; 
register short 71; 
staticBool priority_allocated = FALSE; 
if (!priority_allocated) { 
Polyhedron *obj; 
short i; /* Used within macro. */ 
for (obj = Object_pool; obj < Object_pool + n; 0bj1++) 
Alloc_2d_array(Ubyte, 0bj priority, Total_systems, Total_objects); 
priority_allocated = TRUE; 
} /* end if (priority-allocated) */ 
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for (0bj1 = given_obj; obj1 < hi_obj; obj1++) { 
il = Ws Dye index; 
pri = (*0b71) > priority|syst}; 
for (0bj2 = obj1 + 1; ob i; < obj: obj2++) { 
pril(sobj2) > indes = (*0bj2) > priority|syst||i1] = 
which_obj-is_first(*obj1, *0bj2, syst, critical); 
} /* end for (0bj2. */ 
} /* end for (obj1...) * 


} /« end priorities() */ 


Now we can sort the objects by means of the mikado algorithm. 


Bool sort_objects(order, n, given_obj, critical) | 
(—> Proto.h) 
register Ubyte order| |; /* Probable result (indices of objects). */ 
short n; /* Number of objects. Note that the sorting algorithm runs in 
quadratic time with n. */ 
Polyhedron +given_obj| |; /* Array of pointers to objects. +/ 
Bool critical; /* Can we rely on separating planes? «/ 
{ /* begin sort_objects() */ 
register short i, 7; 
register Polyhedron +*+o0b7; 
static Ubyte «prior = NULL;® 
/* This is an array of pointers in which we store all the priorities. Because 
it may vary in size, we allocate it dynamically with its maximum size. 
*/ 
static Polyhedron +«res_obj; 
/* This is an array of pointers to the residual objects. It is allocated at 
the same time as prior. */ 
static Bool *is_in_front, *is_in_back; 
/* Arrays that indicate whether an object is a front object, a back object 
or neither of the two. +/ 
Ubyte i_min, i_maz, il, 12, k; 
if (prior == NULL) { 
Alloc_ptr_array(Ubyte, prior, Total_objects, "prior"); 
Alloc_ptr_array(Polyhedron, res_obj, Total_objects, "res"); 
Alloc_array(Bool, is.in_front, Total_objects, "front"; 
Alloc_array(Bool, is-in_back, Total_objects, "back"; 


for (i= 0, obj = given_obj; i <n; i++, obj++) { 
res_obj|i] = *obj; 


Static variables help to avoid unnecessary global variables. A trick to declare 
the size of arrays dynamically is to preinitialize the pointer to the array by NULL. 
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/* Mikado algorithm. +/ 
imin =0; imax =k=n; 
while (k) { 
if (!'mikado_select(isin_front, is_in_back, k, res.obj, prior)) { 
if (critical) { 
Print("Gordian knot while sorting the objects\n"); 
for (i = 0; i< k; i++) { 
order|i-min + 1] = res_obj|i] > indez; 
fprintf(Output, "is ", res_obj|i]->name); 
} /* end for (2) */ 
Print("Next time try to split some of these objects"); 
} /* end if (critical) */ 
return FALSE, /* If not critical, we have another try! */ 
} /* end if (mikado-select) */ 
k =0; 11 = i_min; 12 = 1t_-maz; 
for (i=i1, obj = res_obj; i <i2; i++, obj++) { 
j = («obj ) > indez; 
if (is_in_back[j]) 
order|i_min++] = j; 
else if (is_in_front|j]) 
order |——i-mag] = j; 
else 
res_obj[k++] = *obj; 
} /*end for (2) */ 
} /* end while (k) +*/ 
return TRUE; 
}  /« end sort_objects() */ 


Cod 


The Boolean function mikado_select() determines all the objects that either do 
not obscure any other objects or that are not obscured by any other objects. It 
returns FALSE if sorting is not possible. 


TTT TT 
Bool mikado_select(is.in_front, is-in_back, n, res_obj, prior) (— Proto.h) 
Bool is_in_front| |, isin_back| |; 
short n; /* Number of objects. */ 
Polyhedron + res_obj| |; /* Pointer to objects. */ 
Ubyte «prior[ ]; /* Pointers to priority list. «/ 
{ /* begin mikado_select() */ 
register Polyhedron *+obj, *0bj2, **hi_obj =res.obj +1, 
Ubyte *prior1; 
Ubyte 1, J; 
for (obj = res_obj; obj < hi_obj; obj ++) { 
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t = (*o0bj) > indez; 
is_in_front[i] = is_in_back[i] = TRUE; 


for (obj = res_obj; obj < hi-obj; obj ++) { 
i = (xobj) > indez; 
prior! = prior{|il; 
for (0bj2 = res_obj; obj2 < hi-obj; obj2++) { 
if (xobj == *0bj2) continue; 
j = (*0bj2) > indez; 
if (prior 1[j] == i) { 
is_in_back|i] = FALSE; 
if (!is.in_front|i|) break; 
1 else if (prior1[j] ==) { 
is_in_front|i] = FALSE, 
if (!2s_in_back|i]) break; 
} /* end if (prior1) */ 
} /* end for (0bj2) */ 
} /* end for (obj) */ 
/* Check whether search was successful. */ 
for (obj = res_obj; obj < hi-obj; obj ++) { 
i = (*0bj ) > index; 
if (is_in_front(i] || isin_back|i]) 
return TRUE: 
} /* end for (obj) */ 
return FALSE; 
} /* end mikado-_select() */ 


For the correct rendering of the scene, we now simply have to call the function 


void sort_.and_render_objects() (— Proto.h) 


{ /x begin sort_and_render-objects() */ 
short 1; 
static Ubyte «order = NULL; 
static Polyhedron +«obj_ptr; 
/* Array of pointers to objects. */ 
Bool critical, success; 


if (order == NULL) { /* Initialize before drawings. */ 
Allocarray(Ubyte, order, Total_objects, "sort"); 
Alloc_ptr_array(Polyhedron, obj_ptr, Total_objects, "ptr" ); 
for (i = 0; i < Total_objects; i++) 
obj -ptr|i] = &Object_pool |i}; 
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for (critical = FALSE; ; critical = TRUE) { 
priorities(Total_objects, obj-ptr, SCREEN_SYST, critical); 
success = sort_objects(order, Total_objects, obj-ptr, critical); 
if (success || critical) 
break; 


if (!success) { 
Print("Bad visibility test! \n"); 
Print("The drawing order may be wrong! \n"); 


/* Plot entire scene. */ 
for (i =0; i < Total_objects; i++) 
plot_object(obj_ptr|order|i]}); 
} /* end sort_and_render_objects() */ 


5.7 The Creation of Object Groups 
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FIGURE 12. A scene that consists of several object groups. 


The algorithm we described in Section 5.6 only works for “objects,” i.e., poly- 
hedra. Once a scene gets more complicated, the number of objects will of course 
increase. The sorting time, however, runs in quadratic time with the number of 
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objects. Therefore, it is a good idea to check whether it is possible to combine 
several objects in an “object group.” 


The scene in Figure 12, for example, consists of several groups of simple polyhe- 
dra. Instead of checking the priority of each pair of polyhedra, we can determine 
a priority list of the groups and then plot the scene group by group. For scenes 
with lots of objects (Total_objects > 50), this can mean an enormous increase 
of speed in the sort algorithm. 


Two questions, however, remain: 


1. Is it always possible to arrange the objects in groups that can be separated 
by planes? (Which is the prerequisite for the painter’s algorithm. ) 


2. Is it always possible to sort the groups? 


The answer to the first question is yes, if we allow a group to consist of only 
one object as well (in the worst case, we declare each object as a new group). 
Nevertheless, the creation of object groups will only reduce calculation time when 
there is a reasonable proportion between the number of groups and the number 
of objects. 


The answer to the second question is no. Even if we have arranged the objects 
of our scene in groups that can be separated from each other, it may happen 
that we have to undo a “Gordian knot.” The reason for this is that it is hard to 
find out whether the images of two groups are disjoint, even if their bounding 
rectangles overlap. The creation of object groups can still be a great advantage in 
such a case. If the polyhedra {A;} are elements of one group and the polyhedra 
{B;} elements of another group, and if we know the priority between these two 
groups, all the priorities (A;, B;) are determined automatically. In a few cases, 
however, this can be a dead end. As we have said, it is sometimes necessary to 
make use of the fact that between two objects there is no priority because their 
images are disjoint. (Otherwise we might try to undo a “Gordian knot.” ) In these 
few cases, we have to do the sorting without the use of object groups. 


Bounding Boxes and Separating Planes 


Throughout this chapter we have seen that “bounding boxes” and “separating 
planes” play an important part in the determination of priority lists. In this 
section, we want to describe in detail how bounding boxes and separating planes 
between disjoint convex sets can be found. Because the objects of our scene 
will generally keep their relative positions, these calculations can be done before 
starting the animator and have to be adapted once an object of the scene is 
animated separately. 


Let us develop a code for the determination of a bounding box. This array of 
vectors stores the coordinates of the eight vertices of a rectangular box that 
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circumscribes the object in the world system. In the most convenient case, the 
sides of the box are parallel to the coordinate axes. To keep the volume of the 
box as small as possible, it is a good idea to calculate the box immediately after 
the object has been defined and before it is manipulated by means of rotations: 
#define EPS1 1e-4 (— Macros.h) 


void bounding_box(box, n, v) (—> Proto.h) 

Vector box[8]; /* Into this array we write the result. «/ 

short n; /* Number of points. */ 

register Vector v| |; /* Arbitrary set of points. */ 

{ /« begin bounding-boxz() */ 

Vector m[2]; /* Space for two Vectors. */ 

Vector *min = m, *maz = m+1; /* For the argument lists. «/ 

short i; 

min_maz_vec-_of _pool(min, maz, n, v); 

/* Make sure that none of the coordinate differences is too small. This can 
only happen when all the points are on a plane that is parallel to a 
coordinate plane. The result could be an ambiguity in the priority test 
and — in the worst case — a division by zero later on. */ 

for (i =0; i < 3; i++) 
if (Is_zero((*maz)|i] — (*min)[i])) { 

(#min) [i] —= EPS1; (*maz)[i] += EPS1; 
} /* end if */ 
create_coord_box(boxz, min, maz); 
} /* end bounding_box() */ 


For the result, we needed two functions that are useful in other parts of the code 
as well. First we calculate the minimum and maximum coordinates. 


#define Min-_max(min, maz, x)\ (—> Macros.h) 
if (x < min) min = z;\ 
else if (x > maz) maz = 7; 

#define Min_maz_vec(min_v, maz-v, v) {\ (—> Macros.h) 
Min-max((min_v)[X], (max_v)[X], (v)[X]);\ 
Min_maz((min_v)[Y], (maz_v)[Y], (v)[Y])3\ 
Min_maz((min_v)[Z], (maz_v)[Z], (v)[Z]);\ 


| | 
void min_maz-vec-_of _pool(min, maz, n, v) (— Proto.h) 
register Vector «min, «maz; /* Pointers® to the result. «/ 


®The first two arguments of the function are pointers to Vectors. We can 
also pass Vectors, because the corresponding function only takes the address 
of the first element in the array. For superior style, however, we should pass a 
Vector v as (Vector *) v in this case. 
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short n; /* Number of vectors. +/ 
register Vector +v; /* Array of vectors. */ 
{ /* begin min-maz-vec-of -pool() */ 
register Vector *hivu =v+n; 
Copy_vec(xmin, *v); Copy-vec(*maz, *v); 
for (v++; u < hi_v; v++) 
Min_maz_vec(*min, *maz, *v); 
}  /* end min-max_vec-of -pool() */ 


— -—- —— 
ry, 
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FIGURE 13. How to create a “coordinate box.” 


Next we create a box, the sides of which are parallel to the coordinate axes. It 
is given by the minimum and the maximum coordinates, i.e., the coordinates of 
two opposite vertices of the box (Figure 13): 


[Oe ee 
void create-coord_box(bor, min, maz) (— Proto.h) 
register Vector boz{8); 
register Vector *min, *maz; 


{ /* begin create_coord_box() */ 
register Vector +hi_bor = bor + 8; 
staticUbytecorner[8][3] = { 0,0,0, 1,0,0, 1,1,0, 0,1,0, 0,0,1, 1,0,1, 1,1,1, 
0,1,1}; 
register Ubyte «c = (Ubyte *) corner; 
for (; bor < hi_box; box++) } 
(*box)[X] = (*c++ ? (xmaz) : (*min))[X]; 
(xbox)[Y] = (*c++ ? (xmaz) : (*min))[Y]; 
(xbox)[Z] = (*c++ ? (kmaz) : (*min))(Z]; 
} /* end for «/ 
}  /* end create_coord_box() */ 
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Now let us see how we can use bounding boxes for the determination of a sepa- 
rating plane between two objects: 


Let O; and O2 be two (convex or not convex) objects with the bounding boxes 
B, and Bo. Each box has eight vertices and six faces. The planes of each face will 
not intersect the corresponding object and are, therefore, potential separating 
planes. Thus, we will do the following: 


We take the first face of B, and find out on which side of the face the object O; 
lies. (This is done by checking one vertex of O, that is not on the plane of the 
face.) If all the vertices of O2 are on the opposite side of O,, we have found a 
separating plane. Otherwise we continue the search with the other faces of B,.’ 


If none of the faces of B, is a separating plane, we continue the search with the 
faces of Bo. 


If that does not work either and if none of the objects are convex, we give 
up. (Separating planes are a good tool to speed up the program, but they are 
not necessary for the priority algorithm.) If O, and/or O2 are convex, we may 
continue our search for a separating plane. Each plane of a face of a convex object 
is a potential separating plane! 


| 
void sep_plane_between_obj(s, obj1, obj2) (— Proto.h) 
Halfspace * s; 
Polyhedron * 0bj1, +*0bj2; 
{ /x« begin sep_plane_between_obj() */ 
Halfspace * plane, *hi_plane; 
Vector dist, *normal; 
short side; 
float cnst; 
Polyhedron * temp; /* Used in the Swap macro. +/ 
Face «f, «hi_f; 
register Vector * v; 
Vector *lo_vec, *hi_v; 


/* When the soap bubbles that contain the objects do not intersect, it is 
neither necessary nor useful to calculate a separating plane. */ 


Subt_vec(dist, *0bj1—>barycenter, *0bj2—>barycenter); 
if (Length(dist) > (obj1—>maz_rad + 0bj2-—>maz-rad)) { 
s>info= USE_SOAP_BUBBLES; 


return ; 


} 


"Note that the test also works for objects with only one face (i.e., simple 


polygons), because the bounding box is a little removed from the polygon’s 
plane. 
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/* In many cases, the faces of the bounding boxes are themselves separating 
planes. */ 


for (side = 1; side >= —1; side —-= 2) { 
hi_plane = (plane = Sep-pool + obj1—>sep-start) + 6; 
hiv = (lo.vec = 0bj2—>bounding_bor) + 8; 
for(; plane < hi-plane; plane++) { 
normal = (Vector *) plane—> normal; 
cnst = plane—>cnst + 0.005 + fabs(plane —>cnst); 
/* This is a certain tolerance we should admit for inaccurate 
calculations that might occur. */ 
for (v= lo_vec; u< hiv; v++ 
if (Dot_product(*normal, *v) > cnst) break; 
if (v == hiv) 
*S = *plane; 
s—>info= side; 
return ; 
} /* end if (v) */ 
} /* end for (plane) */ 
Swap(obj1, obj2); 
} /* end for (side) */ 


/* We still have a chance of finding separating planes, but only if at least 
one of the two objects has a convex outline! Then \ any of its faces might 
be a separating plane. */ 


for (side = —1; side <= 1; side += 2) { 
if ((Is.convex(obj1) || 0bj1->geom_property == HOLLOW) 
&& obj1—>no_of faces > 1) { 
hi.f = (f = obj1—faces) + obj1—>n0o-0f faces; 
hiv = (lo.vec = obj2— vertices) + obj2—>no_of-vertices; 
for (; f < hi_f; f++) { 
normal = (Vector «) f—>normal; 
cnst = f—>cnst; 
for (v= lovec; v< hi_v; v++) 
if (Dot-product(+normal,*v) < cnst) break; 
if (v == hiv) { 
Copy-vec(s—>normal, *normal); 
s—>cnst = cnst; 
s—>info= side 
return ; 
} /* end if (v) */ 
} /* end for (f) */ 
} /* end if (Is_convez) «/ 
Swap(obj1, obj2); 
} /* endfor (side) x/ 
s—->info = NOT_FOUND,; 
}  /* end sep_plane_between.obj() */ 
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Advanced Features 


Nowadays, people are used to seeing perfect computer-generated images and even 
computer-generated movies of incredible realism. The gap between the products 
of professional computer graphics studios and the possibilities of less sophis- 
ticated graphics computers is enormous. Therefore, it is important to put an 
emphasis on the acceleration of programs that produce an acceptably realistic 
output. 


In Chapter 5, we saw that the painter’s algorithm is a powerful tool for the quick 
rendering of even complicated scenes. This algorithm must, of course, be used 
with our special object preprocessor, which splits objects according to their type. 


One of the first to extend the painter’s algorithm to the plotting of cast shadows 
was Crow [CROW77]. His ideas turned out to be very useful for scenes with 
comparatively few faces. In recent times, however, most people have preferred 
different algorithms like ray tracing or the radiosity method [GORA84, ROGE90| 
for this purpose. These algorithms work for any kind of scene and are also capable 
of doing reflections and transparencies (refractions). They have only one great 
disadvantage: they take a lot of computation time. 


In this chapter, we will see that the painter’s algorithm can be used to add 
shadows, simple reflections and refractions, without any major loss of time. To 
get perfect images of a scene, we can still use more sophisticated algorithms and 
shading models. We can call this program a “movie maker.” 


To fulfill our task in an efficient manner, we have to insert two important sections 
about convex hulls. 
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6.1 Convex Hulls 


In Section 5.5, we had to intersect the outlines of two objects in order to deter- 
mine which one was to be plotted first. An outline is nothing but the projection 
of the contour polygon of the object onto the image plane. 


Let us first develop a function spatial_hull(), which determines all the contour 
edges of a polyhedron with convex outline. 


Usually, a contour edge is the side that a frontface and a backface have in com- 
mon. (When the object consists only of one single face, each side of the face is 
a contour edge.) Because we know the neighboring faces of each face, for each 
backface of the polyhedron, we just have to check whether it has neighboring 
frontfaces. If this is the case, the common edge of the two faces is stored. Note 
that the function works both in the screen system and in the light systems. 


#define Screen_to_light(v, n) (Light_pool[n] + (v — Screen_pool)) 


(—> Macros .h) 


[. | 
void spatial_hull(obj, syst) (— Proto.h) 
Polyhedron * obj; /* Polyhedron with convex outline. */ 
short syst; /* Screen system and light systems. */ 


{ /* begin spatial_hull() «/ 
register short 7; 
register Face + f, +f1, *hi_f; 
static Edge edge_pool| MAX_POLY_SIZE); 
Edge «edge = edge-pool; 
Vector **contour(1|; /* Space for one pointer. */ 
short n, size; 


face.types(obj, syst); 
hi.f = (f = obj-—>faces) + obj >no_of_faces; 
for (; f< hi_f; f++){ 
if (f—>darkfacelsyst|) continue; 
n = f—>no-of-vertices; 
for “(= 0; i< n; i++) 
fl = (Face *) f—>neighbor_faces[i]; 
if (f1 == NULL || f1—>darkfacelsyst}) { 
edge—>vl = Soren doent f > vertices 
edge—>v2 = Screen_to_light( f vertices 


} [Noad if (fl...) 4/ 
} /*x end for (i...) +/ 


} /* end for (f...) */ 
n = edge — edge_pool:; 





i], syst); 
(@+1)% n], syst); 





contour|0] = obj >contour|syst}; 
concat.to_polygons(&n, &size, contour, n, edge_pool, TRUE); 
0bj —> size_of _contour|syst] = n = size —1; 


orient_ptr_poly(n, contour|0}); 
} /* end spatial_hull() */ 


Section 6.1. Convex Hulls 157 


The function spatial_hull() calls a routine that connects the edges to a (closed) 
polygon. More generally, it is also able to connect sets of edges to several poly- 
gons. For example, the contour polygon of a polyhedron that is an approximation 
to a torus will consist of two (closed) branches. 


Bool concat_to_polygons(no_of _-branches, branch-_size, branch, 
n, edge-_pool, is.a_convex_contour) (— Proto.h) 
short *no_of_branches; 
short *branch-_size; /* Size of each solution curve. */ 
Vector * * «branch; 
/* Pointer to an array of pointers to the vertices of the polygon. branch|0| 
has to be allocated outside the function! */ 


short n; /* Number of edges. +/ 
Edge +edge_pool: /* Given edges. + / 
Bool is_.a_convex_contour; 


{ /« begin concat_to_polygons() */ 
register Edge * edge; 
register Vector * succ; 
register short i, j; 
Vector **v = branch|0], * * hi_v; 
Vector * start. -point, 
short side, k = 0; 


* no.of branches = 1; 
if (n == 0) 
branch_size[0| = 0; 
return FALSE; 
} /* end if (n == 0) */ 
while (n) 
branch|k] = v; 
edge = edge-pool; 
eu++ = edge>vl; 
eu++ = edge >v?2; 
edge_pool|0| = edge_pool|——n]; 
/* Replace first edge by last one. */ 
branch_size|k] = 2; 
hiv = v+ 2 *n; 
succ = branch(tt} 
for (side = 0; side < 2; side ++) { 
sare paint = branch{k] (0); 
do 
for (i= 0, edge = edge_pool; i< n; i++, edge++) 
if (edge ul == succ) { 
succ = edge—>v2; 
break; /* Quit the loop for (i...). */ 
} else if “(edge= >v2 == succ) { 
succ = edge—>vl; 
break; /* Quit the loop for (i...). */ 
} /* end if (edge—>v1...) */ 
f i@==n 
succ = NULL; 
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else { 
if (v >= hiv) { 
Print("branch too long"); 
break; /* Quit the loop while (n). */ 
} /* end if (uv...) */ 
*U++ = SUCC; 
edge-pool|i] = edge-pool|——n]: 
/* Replace edge that has been found by last one. */ 
} /* end if (¢ == n) */ 
} while (succ && n > 0 && succ! = start_point); 
branch_size[k] = uv— aie 
if (succ == start_point) ‘ * Closed polygon. */ 
if (is_a_convex-_contour 
return TRUE; 
else 
break; /* Quit the loop for (side...). */ 
} else if (is_a_convezx-contour) 
Print("Warning: contour is not closed"); 
return FALSE; 
} /* end if (succ == start_point) */ 


if (side == 0) { 
Vector *temp, **b1, * * 62; 


/* Since we will now search in the other direction we store the 
branch ‘upside down.’ */ 
succ = start_point; 
b1 = branch|k]; 62 = b1 + (branch-size[k] — 1); 
for (; bl < 62; b1++, b2-—-—) 
Swap(*bl1, *b2); 
} /* end if (side) */ 
} [* end for (side) */ 
k+ 


} /x and while (n) */ 
*xno_of branches = k; 
return TRUE; 
}  /* end concat_to_polygons() */ 


For the intersection of two convex hulls, it is necessary that the contour polygon is 
oriented counterclockwise. This can be achieved by a routine orient_ptr_poly(). 
We check whether the area of a triangle that is given by three points of the 
polygon (with the indices i; < ig < i3) is positive or not. If it is negative, we 
change the order of the vertices of the polygon. 

#define Area_ of 2d_triangle(a, b, c) (— Macros.h) 











(B)[¥] — (a) [¥] « (6)[X] + \ 
b)|X] + (c)[Y] — (0) (OLX + \ 
Oa: aly Oly I: ae 


#-define SMALL_AREA le — (local macro) 
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r. , | 
void orient_ptr_poly(n, poly) (— Proto.h) 
short n; 


register Vector + *poly; /* Array of pointers. */ 


{ /* begin orient_ptr_poly() */ 
register Vector *«*pl = poly + 1, **p2 = poly + 2; 
Vector *temp, **hi_p2 = poly + n —1; 
float area; 
short orientation = 0; 


for (; p2 <= hi_p2; pl++, p2++) { 
area = Area_of_2d_triangle(* * poly, ** pl, * *p2); 
if (area > SMALL_AREA) 
return ; /* Polygon is oriented correctly (i.e., ccw). */ 
else if (area < —SMALL_AREA) 
break; /* Orientation must be switched. +/ 
else { /* Delay decision. «/ 
orientation + = Sign(area); 
if (p2 == hi-p2 && orientation >= 0) 
return ; /* Obviously the polygon is very small. 
However, it seems to be oriented correctly. «/ 
} /* end if (area...) */ 
} /* end for (p2...) */ 
/* Switch orientation. */ 
pl = poly; p2 = hi_-p2; 
for (; pl < p2; pl++, p2——) 
Swap(*p1, *p2); 
} /* end orient_ptr_poly() */ 


#undef SMALL_AREA 


Of course, the determination of the spatial hull of an object works much faster 
than a general routine for the determination of the convex hull of an arbitrary 
set of points. Sometimes, however, such a routine can be useful. For this reason, 
we include the listing of a function hull(), which takes an array of n given points 
(Vectors or Vector2s) and which calculates the oriented convex outline. 


In fact, such an algorithm is needed so frequently that many different approaches 
have been tried (some of them are described in [PURG89]). The algorithm we use 
is based on a recursive algorithm by Bykat [BYKA78]. Calculation time increases 
only linearly with the number of points, provided that the points are distributed 
homogeneously. We will not need any trigonometric functions. 


Figure 1 illustrates the idea. In a) we determine the leftmost point Z and the 
rightmost point R of all the given points. The connection LR between these two 
points divides the hull into two convex parts. For both these parts, we now start a 
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FIGURE 1. How to determine the convex hull of a set of points. 


recursion: in b) we identify A with L and B with R and we determine the point C’ 
that has the maximum positive distance from the side AB (see Equation 1). The 
point C’ clearly belongs to the hull. Now C’ assumes the part of B. In c) the 
search for a point C’ is repeated until no other point with a positive distance is 
found. In d) the ultimate point C' is concatenated with A and C’ assumes the 
part of A. In e) the recursion is started again. The algorithm comes to an end 
when there is no point left between B and FR that has a positive distance. Now 
the lower chain is closed and in f) the algorithm is repeated for the upper chain. 


Here is the code of the function hull(): 


typedef float Vec | |; (— Types .h) 
/* This is a “pseudo-type” which indicates that the variable can be either a 
Vector or a Vector2. Pointer arithmetic is not possible with this type, 
since sizeof(Vec) = 0! */ 
typedef struct { 
Vec *p; /* Pointer into given_points. * is 
short next; /* Index of next point in Point_chain. +/ 
} P_ptr; (— Types.h) 


local macro 
#define MAXP 1000 


static P_ptr + Point_chain|MAXP; 


/* Local macros to make the code readable. +/ 
#-define Idz(p) (p — Pointchain) 

#define Nezt(p) (Point_chain|p > saeigel 
#define se pls (p >= Point_chain) 
#define NO.MORE —1 
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| 

void hull(size, result, n, given_points, dim) (— Proto.h) 

short * size; /* Number of points on the hull. */ 

Vec *result| |; /* Array of pointers to the vertices of the hull. The hull is 
oriented ccw.+*/ 

short n; /* Number of given points. */ 

Vec given_points| |; /* Vector2s or Vectors. */ 

short dim; /* 2D or 3D? */ 


{ /x« begin hull() */ 
register float *gp= (float +) given_points; 
register short i; 
float rmaz, rmin, ymax, ymin; 
P_ptr «min, *maz; 
P_ptr + residual; 


if (n > MAXP) 
Print("Too many points for convex hull\n"), 
n = MAXP; 
min = max = residual = Point_chatn; 
for (i= 0; i< n; i++, gp+=dim) 
Point_chain{i].next = 7 + 1, 
Point_chain[i].p = (Vec *) gp; 
Point_chain[n — 1].netzt = NO_MORE; 
gp = (float *) given_points; 
/* Determine min and maz. */ 
zmax = xmin = gp|X]; ymax = ymin = gplY]; 
for (i= 1, gp +=dim;i< n; i++, gp +=dim) { 
if (gp[_X] < zmin) 
amin = gp|X], min = &Point_chainii]; 
if (gp[X] > xmaz) 
amax = gp|X|, max = &Point_chainli]; 
if (gp[Y] < ymin) 
ymin = gplY]; 
if (gp[Y] > ymaz) 
ymax = gplY]; 
} /* end for (7) */ 


/* Remove min and maz. */ 


if (Idx(min) == 0) 
residual+-+; 
else 
(min — 1)—>next = (Idz(min+1) < n? 
Idx(min +1) : (Idz(mar) == 071 : 0)); 
if (maz == min + 1) { 


if ([Idx(min) == 0) 
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residual+-+-; 
else 
(maz — 2) > nest = = mae —> nest; 
} else if (Idz(maz) = 
residual+-+; 
else 
(maz —1)—>nezt = maz—>next; 
* size = 0; 


divide_-points(min, maz, &residual, size, result, 2); 


} /* end hull() */ 


This is the listing of the recursive function divide_points(): 


void dividepoints(min, maz, residual, size, result, sides) 
| (— Proto.h) 
P_ptr *min, *maz; 
P_ptr residual; 
short + size; 
Vec *result| |; 
short sides; /* Trace one or two sides. */ 


{ /* begin divide_points() */ 
float maz_neg_dist = 0, maz.pos_dist = 0; 
P_ptr «lo, «hi;  /* Left and right points in residual. +/ 
P_ptr *p_min, *p-maz; /* Points with max. (min.) distance. «/ 
P_ptr «p, *next_p; 
register float az, ay, nz, ny, dist; 


ht = p-min = pmax = NULL; 
«residual; 
* Left or right? * {, 
nx = (*max ween ] - = (min >p) te 
ny =(ar = (*min >P) X|) — (*maz—>p)| F 
while {s-in_chain(p)) 
/* Distance of p Yobn side. */ 
dist = ((*p—>p) X] — az) nz + ((*xp->p)|Y]—ay) * ny; 
nettp = Nesxt(p); 
if (dist < EPS 
if (dist < max_neg-dist) 
mazx_negdist = dist, 
p-min = p; 
p->nect = Idz(lo); 


= P; 
} else 
if (dist > maz_pos_dist) 
rr poste! = dist, 
p-maxz = 
p>nezt = las( hi); 
ht = p; 
} /*x end if (dist) x/ 


p = nexrt_p; 
} /* end while +*/ 
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if (!Is_in_chain(lo)) { 

/* No point on this side. */ 
min—>next = Idz(maz); 
result|(*size)++] = mar—>p; 

}else if (lo+nert == NO_MORE) { 
/* Insert the only point lo. */ 
min->next = Idz(lo); 
lo>next = Idz(maz); 
result|(xsize)++] = lop; 
result|(*size)++] = max—>p; 


}else { 
/* We are not ready yet (more than one point). */ 
if (lo == p_min) 
lo = Nezt(lo); 
else { 
p = lo; 
while (Nezt(p) != p-min) 


p = Nexzt(p); 
p—>next = Next(p)—>nect; 
} /* end if (lo) «/ 
p-min—>next = NO_MORE; 
divide_points(min, p_-min, &lo, size, result, 1); 
divide_points(p_min, maz, &lo, size, result, 1); 
p = lo; 
} /* end if (Is_in_chain) «/ 


if (sides == 2) { 

if (!Is_in_chain(hi)) { 
/*x No points to insert. Concatenate min with maz. */ 
result|(*size)++] = max—>p; 

}else if (hi>nezt == NO_MORE) { 
/* Only hi found. */ 
max—>nezt = Idz(hi); 
result|(xsize)++] = hi>p; 
result|(*size)++] = max—>p; 


selse { 
if (hi == p_maz) { 
hi = Neat(hi); 
}else { 
p= hi, 
while (Nezt(p) != pmaz) 


p = Nest(p); 
p—>next = Nest(p)>next; 
} /* end if (hi) */ 
p-mazx—>nexzt = NO_MORE; 
divide_points(max, p-maz, &hi, size, result, 1); 
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divide_points(p_maz, min, &hi, size, result, 1); 


p = p-maz; 
while (p—>nezt != Idz(min)) 
p = Nezt(p); 
Po Snes = NO_MORE; 
} /* /s * end t LAF (Zein chain */ 


} [x end if F (sides = == 2) «/ 
x residual = 
}  /* end divide_points() */ 


6.2 ‘The Intersection of Convex Hulls 


For depth comparisons, we have to intersect the convex hulls of two objects. 
Given these two hulls, we look for at least one of the (up to four) intersection 
points (Figure 10). 

The function relative_pos_of hulls() checks whether two hulls overlap or inter- 
sect. Additionally, it stores the z-values (modified by Equation 1.38) of two space 


points, the images of which coincide with an intersection point of the outlines of 
the polygons. 


##-define Is_largeenough(x) (fabs(x) > le—2) (— Macros.h) 
#+-define Between_zero_and_one(t) (t > 0 && t < 1) (— Macros.h) 
a | 
short relative_pos_of hulls(z, n1, hull1l, n2, hull2, syst) (— Proto.h) 


float z[2]; /* z-values of two space points with the same image. */ 
short nl, n2; /* Number of vertices of the hulls. +/ 

Vector *hull1[ ], *hull2[ ]; /* Arrays of pointers. */ 

short syst; 


{ /* begin relative_pos_of _hulls() */ 
register Vector +«al, +*b1; 
register Vector **a2, ++b2; 

/* We will try to intersect two sides (a1b1), (a2b2) of the polygons. An 
intersection point will only be taken into account when it belongs to 
both sides. +/ 

Vector #hi_l = hulll+n1, hi2 = hull2 + n2; 

float 1, 12; /* Parameter values of the intersection point. + / 
float dz, previous-_dz; /* Distance of corresponding points. */ 
Bool delay.decision = FALSE; 

/* If the z-values of the corresponding points differ only slightly (i.e., 
when dz is small), we will not rely on the result. (After all, we are 
talking about the priority between two entire polyhedra!) In such a 
case, we will continue our search for intersection points. +*/ 

Vector2 dl, d2; /* Direction vectors of two edges. +/ 
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for (al = hull1, b1 =al+1; al < hil; al+4, 6144) { 
if (b1 == hil) 61 = hulll; 
Subt_vec2(d1, **al, **b1); 
for (a2 = hull2, b2 =a2+1; a2 < hi2; a2++, b2++) { 
Bool parallel; /* In this case only a “dummy.” */ 
Vector2 s1; /* In this case only a “dummy.” */ 


if (62 == hi2) b2 = hull2; 
Subt_vec2(d2, +*a2, **b2); 
inter sect_lines(sl, &t1, &parallel, **al, dl, **a2, d2, 2); 
if (!Between_zero_and_one(t1)) 
continue; 


if (!I's_zero(d2|X])) 
t2 = ((#*a1)[X] + t1 * d1[X] — (**a2)[X])/d2[X]; 
else if (!Is_zero(d2[Y])) 
t2 = ((**al)[Y] + #1 * d1[Y] — (+*a2)[Y])/d2[Y]; 
else continue; /+ Edge goes through projection center. */ 
if (!Between_zero_and_one(t2)) 

continue; 

z[0] = (#*a1)[Z] + £1 * ((4b1)[Z] — (+*a1)[Z]); 

z[1] = (#*a2)[Z] + £2 * ((4*b2)[Z] — (4*a2)[Z]); 

if (Dist[syst] < 1000) {/* Projection rays not parallel. */ 
T2(z[0], 2[0], syst); T2(z(1], z[1], syst); 

} /* end if (Dist) */ 

dz = z[(1] — z(0); 

if (Islarge_enough(dz)) { 
return INTERSECTION; 

} else { 

/* This is bad for the final priority decision. If such a case has 
occurred before, compare the results. If they are the same, it 
should be okay! */ 

if (delay_decision) { 
if (Sign(dz) == Sign(previous_dz)) 

return INTERSECTION, 
else /« Rely on the better result. +/ 
if (fabs(dz) > fabs(previous_dz)) 
previous_dz = dz; 

} else { 
delay-.decision = TRUE; 
previous.dz = dz; 

} /* end if (delaydecision) */ 

} /* end if (Istarge_enough...) */ 
} /* end for (a2...) */ 
} /* end for (al...) */ 
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if (delay_decision) {/* Still??? Tough luck! «/ 
Print("Critical intersection of polygons\n"); 
return INTERSECTION, 
/* Keep your fingers crossed and continue! */ 


} 

if (inside_poly(+*(hull1[0]), n2, hull2, syst, z)) 
return POLY1_INSIDE_POLY2; 

else if (inside_poly(*(hull2(0]), n1, hulll, syst, z)) 
return POLY2_INSIDE_POLY1, 

else 
return DISJOINT: 

} /* end relative_pos_of _hulls() */ 


The last function calls another function inside_polygon(), which determines 
whether a point is inside the image of a closed spatial polygon or not. 


Figure 2 shows how the problem can be solved. Let 7 be the normalized normal 
vector of a line PQ. With the implicit equation of PQ iz = tip = const (see 
Equation 10), we can determine the oriented distance of a point R (position 
vector 7) from the line PQ: 


dp =iPR=i(7-p) =F — const. (1) 


If 7 is not normalized, the number daz will be the distance scaled by the constant 
length of 7. 


To determine whether a point Q is inside a given convex polygon P or not we 
do the following: we draw a line from the first point P of P through Q and 
check whether there is a residual intersection point P with the polygon P. Such 
@ point exists when we can find two vertices R and S of P that lie on different 
sides of PQ (sign(dr) ¥ sign(ds)). (Otherwise Q is outside the polygon.) The 
residual intersection can then be calculated by means of a linear interpolation: 


p=7r+t(s—7) with t =dpr/(dez—ds). (2) 


Now the point Q is inside the polygon P, when it is inside the segment PP 
(0 <A =|PQ|/|PP| < 1), otherwise it is outside the polygon. 


In our case, the given polygon P is the spatial hull of a convex object. Therefore, 
our function inside_poly() can also check whether the space point Q is behind that 
polygon or not: we just have to compare the z-value of Q with the interpolated 
z-value of a point Q that lies on PP, and the image of which coincides with the 
image of Q. 
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FIGURE 2. How to find out whether a point is inside a convex polygon or not. 


Bool inside_poly(q, n, poly, dist_syst, z) 
(— Proto.h) 
float q|];_ /* Point Q that is to be checked. «/ 
short 1; /* Size of polygon. */ 
Vec +«poly; /* Array of pointers to the vertices of the polygon. */ 
float dist_syst; /* Distance of proj. center (only for dim = 3). */ 
float z[]; | /* z-values of Q and Qo. */ 


{ /x begin inside_poly() */ 
float xp = **poly; /* First point P on polygon. */ 
float «r, +s; /* Side RS of the polygon. */ 
float dist_r, dist_s; /* Distances of these points. */ 
float p0(3];  /* Residual intersection point Pp on PQ. */ 
float normal[2], cnst; /* Implicit equation of PQ. */ 
register short 7; 
register float t; /* Parameter. */ 


/* Implicit equation of PQ. */ 
normal[X] = q[Y] —p[Y]; normal[Y] = p[X] — 4X]; 
enst = Dot_product2(p, normal); 
/* Check distances of residual vertices on polygon. +/ 
r = x(poly[1]); | /* The second vertex of the polygon. */ 
distr = Dot_product2(r, normal) — cnst; 
for (i= 2; i< n; i++) { 
s= *(poly[i]); /* The (¢+1)-th vertex of the polygon. */ 
dists = Dot-_product2(s, normal) — cnst; 
/+* Are R and S on opposite sides of PQ? */ 
if (Sign(dist_r)!= Sign(dist-_s)) 
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break; 
r = 8s; distr = dist_s; 
} /*x end for (2) */ 
if (ji ==n) /x* All the points are on the same side. */ 
return FALSE; 
/* Interpolate intersection point Po. */ 
t = dist_r /(dist_r — dist_s); 
for (i = 0; i< Dim; i++) 
po] = r[é] + t* (s[i] —r[é)); 
/* Calculate ratio PQ / PPp. */ 
/* Which coordinate is more accurate? */ 
i = fabs(p0[X] —p[X]) > fabs(pO[Y] —plY])?X : Y; 
t = (q{t] — plé]) /(p0[t] — pli] + EPS); /* No div. by zero! */ 
if (!Between_zero_and_one(t)) /* Q is outside the interval. */ 
return FALSE; 
if (Dim == 3) {/* z-values of Q and Qo. */ 
float w1,w2; /* Apply Transformation T2. */ 
T2(z[0], q[Z], syst); 
T2(wl, p[Z], syst); T2(w2, p0|Z], syst), 
zl] = (1 — t) * wl + tx w2; 


return TRUE; 
} /* end inside_poly() */ 


The functions we have described so far in this chapter are quite useful for priority 
determinations and — as we will see in Chapter 7 — for hidden-line algorithms. 
For the clipping of filled polygons, we need another very important function 
clip_convex(), which determines the intersection polygon of two convex polygons. 
This function is one of the most frequent routines in our program. We need it, 
for example, every time we plot a shadow polygon or — as we will see in the 
following section — when we clip a polygon with a reflecting face. Therefore, it 
has to be perfectly optimized. 


In Section 2.5, we explained the Hodgman-Sutherland algorithm for the clipping 
of an arbitrary polygon with the drawing window. The rectangular drawing area 
is just the special case of a convex polygon. The obvious thing to do is to extend 
the algorithm to the clipping with general convex polygons. 


Figure 3 shows how this can be done: we cut the given polygon P (which may be 
convex or not) with each side of the clipping polygon C (in an arbitrary order). 
A side PQ (position vectors p and q) of C divides the image plane into two 


halfplanes. Let 7 be the oriented normal vector of PQ (7 points to the outside 
of C). Then the implicit equation of PQ nz = np = const (see Equation 10) 
helps to determine whether a point R (position vector 7) is on the same side 
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as C or not: if the sign of dg (Equation 1) is positive, R is on the opposite side 
of C. 


We now check on which side of PQ all the vertices of P are on. When all the 
vertices are on the same side as C, we do not have to clip. When all the vertices 
are on the opposite side, the polygons are disjoint and we are finished. When 
the vertices of P are scattered on both sides of PQ, we do the following for all 
sides RS of P (in ascending order): if dz is not positive, the vertex R belongs to 
the new polygon; if sign(dr) # sign(ds), we calculate the intersection point So 
(position vector 59) of PQ and RS by means of a linear interpolation (Equation 2) 
and add Sp to the new polygon. 





FIGURE 3. How to clip a polygon with a convex polygon. 


If you take a closer look at the source code of clip_convez() you will see how this 
algorithm can be implemented by means of pointer arithmetic, which makes the 
function efficient and needs less memory. 


#define STATIC static (— Macros.h) 
/* If the value of a local variable is only needed as long as the function is 
active, we will not declare the variable static, since this takes extra RAM. 
static variables speed up the code, however, because they do not have to be 
allocated at the stack each time the function is called. When your system has 
enough RAM left, you can accelerate functions that are needed frequently 
by declaring some temporary variables static. If you run out of RAM, write 


#define STATIC 
*/ 
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short clip_convex(n1, poly, n2, clipping_poly, inter, which, dim) 
(— Proto.h) 
/* This function returns the number of vertices of the intersection polygon. 


*/ 
float poly[], clipping-poly| |; 

/* clipping_poly must be convex and should be oriented ccw. */ 

short nl, n2; /* Corresponding numbers of vertices. */ 
float inter[ ]; /* To make room for the intersection polygon. */ 
float x*«which; 

/* This pointer to a polygon indicates whether clipping_poly is the inter- 
section polygon. This will frequently be the case and can help to save 
time. (For example, if poly is a shadow polygon and clipping-_poly the 
outline of a face, and if the intersection polygon is clipping-poly, the 
whole face will be dark and we do not have to calculate any further 
shadows.) */ 

short dim; 
/* This function works both for Vector2s and Vectors. «/ 


{ /* begin clip_convex() */ 

register Ubyte j; 

STATIC float * sp1[MAX_POLY_SIZE), *sp2|MAX_POLY_SIZE); 
/* Space for pointers to the vertices. «/ 

register float *«r; 

float rl = spl, * *7r2;/* Switch between spl and sp2. */ 

STATIC float dist| MAX_-POLY_SIZE}; /* Distances. */ 

float cnst, t; 

STATIC float space[2 + MAX_POLY_SIZE * sizeof(Vector)]; 
/* Space for intersection points. +/ 

float *new = space; /* Coordinates of a new vertex. */ 

Ubyte opposite, 1, size = n2; 

float «a, *b; 

Vector2 n; /* The normal vector. */ 

Bool flip = FALSE; 


* which = clipping-_poly; 
/* We assume that clipping_poly is the intersection polygon. */ 
= rl, b = clipping-poly; 


for (j = 0; 9 < size; j++, b6+= dim) 
rij] = 6; 
for (i = 0; 7< nl; i++) { 


a = poly + i «dim: 

b= (i+ 1 < nl? a+ dim : poly); 
n[X] = O[Y] —alY]; n[Y] = a[X] — 6[X]; 
t = fabs(n[X]) + fabs(n[Y]); 

if (t< EPS) continue; 

n[X] /= 4% nfY] /= 


} 
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/* Pseudo-normalizing for numerical reasons. */ 
cnst = Dot_product2(a, n); 
if (== 0) { /* Check orientation of 7i. */ 
b+=dim; /* Test point poly[2]. «/ 
if (Dot_product2(b, n) —cnst > EPS) 


flip = TRUE; 
} /* end if (¢ == 0) x/ 
if (flip) 


cnst = —cnst, n[X] = —n[X], n[Y] = —nlY]; 
r= rl; opposite = 0; 
for (j = 0; 7 < size; j++, r++) 
if ((dist[|j| = Dotproduct2(*r, n) —cnst) > EPS) 
opposite++; 
if (opposite == size) 
return 0; /* Polygons are disjoint. */ 
if (l!opposite) 
continue; /* No clipping with this side. */ 
/x We will find intersection points. */ 
dist|size] = dist(0|; 
ri[size] = r1{0); 
r= 72 = (rl ==spl? sp2 : spl); 
for (j = 0; 7 < size; j++) 
if (dist|j] <= EPS) 
r++ = r1[j]; 
if (dist[j] * dist|j + 1] < 0) { 
/* Linear interpolation of the intersection point. +/ 
a = rifjj; b= rifj + 1); 
t = dist|j] /(dist[|j| — dist{j + 1]); /*0<t<1 */ 
new[X] = a[X] + t* (0[X] —alX)); 
= alY] + t* (0[Y] —a[Y]); 
if (dim == 3) 
new|Z] = a[Z] + t* (b[Z] — a[Z)); 
r++ = new; 
new += dim; 
x which = inter; 
} /x end if (dist[j] * dist[j + 1] < 0) */ 
} /x end for (j < size) */ 


size = r—(rl = 12); 

} /*x end for (4 < nl) */ 

if (*which == clipping-poly) 
return 72; 

r= rl,a = inter; 

if (dim == 2) 


for (j = 0; j < size; j++) 
sat+ = (#r)[X], xat+ = (#r++)[¥]; 
else 
for (j = 0; j < size; j++) 
eat+ = (#r)[X], eat+ = (#r)[Y], xat+ = (xr ++)[Z]; 
return s2ze; 
/* end clip_convez() */ 


Co 
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6.3 


Shadows 


Shadows are very important for the realism of computer-generated images. With- 
out shadows, the images appear two-dimensional, and depth comparisons can be 
misleading. Since shadows are projections from the light source, a scene with 
shadows can be interpreted as a multiple projection (in one and the same im- 
age). This allows human imagination to reconstruct the scene in space. 


A “shadow” is defined as the darkness cast by an illuminated object. In nature, 
we are used to seeing images that are illuminated by one single light source that 
is at an “infinite distance” (provided that the weather is fine). Artificial light 
sources can be multiple and need not necessarily be point sources. In computer 
graphics, only few algorithms are known that produce the shadows of all kinds of 
objects. Of course, ray tracing [GLAS90] and the radiosity method [FOLE90] are 
among these algorithms. Another one (“shadow buffering” [THAL87, FOLE90)}) 
will be discussed in detail in Section 7.4. 


In this section, we will see how the shadows of polygons can be generated by 
means of a method that is based on convex polygon-clipping. Usually, it takes a 
lot of computation time to plot shadows. Under specific circumstances, however, 
this is not necessarily the case, as we will see in this section. 


FIGURE 4. The clipping of shadow polygons. 


Let L, be the n-th light source and let P, and P» be two closed planar polygons 
(Figure 4) in space. From the geometrical point of view, the light system con- 
nected with L,, (Section 2.3) is the same as the screen system connected with 
the projection center C. In the screen system we say: when the images (i.e., 
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the projections onto the image plane 7) of the polygons P; and P» overlap, the 
one that is closer to the projection center obscures (parts of) the other polygon. 


When we apply the painter’s algorithm, the obscured polygon has to be plotted 
first. 


The analog in the n-th light system is: when the projections on the imaginary 
projection plane 7, of the light system of P, and P, overlap, the polygon that is 
closer to L, casts shadows on the other polygon. When we apply the painter’s 
algorithm, we add these shadows immediately after having plotted the shadowed 
polygon. Then we do not have to think about visibility. 


The shadow polygon S can be added by means of 2D-clipping. The (convex) 
intersection polygon S" (with the vertices S”) of the projections P{ and Py, of 
the polygons has to be -projected onto the plane w that carries the shadowed 
polygon. For this purpose, we intersect the light ray L,S” with ~, and we get 
the vertices S of the shadow polygon S. 


For a more accurate computation, this projection should be done in the world 
system. In the light system, a vertex S” of the intersection polygon S”, which 
lies entirely on the projection plane 7,, may have the position vector s”. In the 
world system, we get the coordinates of points on 7,, by transforming their light 
coordinates by means of a simple rotation, which is described by the matrix 
R=! = InvRot[n] (s*” = 3" Rz!). We intersect the ray L,S" with the plane 7 
of the face and we get a vertex S of the shadow polygon in space. The projected 
point S¢ = CS 7 is a vertex of the image of the shadow polygon. 


Which color should we choose for the shadow polygon? For sophisticated illu- 
mination models, this is a very difficult question because the color may vary for 
each pixel, depending on reflections from other objects, the colors of other light 
sources, etc. For our purposes, it will be enough to fill small shadow polygons 
with one and the same shade of a color, and, when the polygon is large, to vary 
the shade slightly, depending on its distance from the observer. Furthermore, the 
color of the shadow will only depend on the color of the face and it will not — as 
in more advanced models — be influenced by the colors of the light sources or by 
those of surrounding objects. This may seem to be a tremendous simplification, 
but in most cases, the images produced in this way are sufficiently realistic. In 
our simplified model, a shadow polygon is basically filled in the same manner as 
the image of the face, only with a darker shade. 


How much darker the shade of a shadow has to be is not subject to any strict 
rules. Imagine two photographs of one and the same building with the same angle 
of incidence of the light rays, but with different light intensities (fog or dust in 
the atmosphere, etc.). The contrast between the shadows and the illuminated 
faces will be different. In general, pictures look realistic if we use approximately 
one-half the value of the variable reduced_palette in Formula (2). 


Since in our illumination model the color of the shadow polygon only depends on 
the color and the depth of the corresponding face, we can plot several (convex) 
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FIGURE 5. Convex polyhedra only cast shadows on other polyhedra and not on 
themselves. 


Section 6.3. Shadows 175 


shadow polygons in an arbitrary order onto the face. The result will be a set of 
(convex or not convex) shadows (Figure 5). 


This way of painting over existing polygons is very efficient, but it has a disad- 
vantage that is due to the fill algorithm of polygons. Let P° be the image polygon 
of a face and let S¢ be the image of a shadow polygon that is not completely 
inside P®. Then P© and S¢ will have part of the side PP of P* in common (e.g., 
the line 9S). Even though from the mathematical point of view the line SS lies 
on PP, the filling routine for S° will not always cover all the pixels that PP and 
SS seem to have in common. (This has nothing to do with the screen resolution. ) 
Some lighter pixels may be left at the border of S°. The reason for this is that all 
the coordinates of the vertices are rounded off before the images of the polygons 
are drawn. One way to avoid such light pixels is to enlarge the shadow polygon 
at each vertex by one pixel. In most cases, this will work and the image will be 
improved. If your compiler has a routine linewidth() that allows to draw thicker 
lines, you can also draw the outline of a shadow polygon with a “linewidth of 
2 pixels.” If you choose a shade for this outline that is a bit brighter than the 
rest of the shadow polygon, you can create an “aura” around it. Artificial light 
sources (which are not perfect point sources) create such auras so that this trick 
is a simple method of simulating this effect without any complicated calculations. 


So far we have only talked about one light source. What happens when we deal 
with several light sources? In this case, we will have shadow polygons of different 
“grade” (this idea is mentioned in [ANGE87]). 


First, we plot the shadow polygons {S;} for all the light sources L;. These poly- 
gons of grade 1 will appear comparatively light, depending on the intensities 
of the residual light sources. Then we clip all the shadow polygons of grade 1 
that are cast by other light sources. Thus, we get shadow polygons of grade 2: 
{S;;} = {S;1 Sj; (i # j)}. They have to be plotted in a darker shade because 
they are not illuminated by two light sources. If we have only two light sources, 
we are finished. Otherwise we have to check whether there are shadow polygons 
of grade 3: {Sijz} = {Si; NSiz (jf # &) }, which will be even darker than the 
shadows of grade 2. The algorithm has to be continued until the grade of shadows 
equals the number of light sources. 


What we have described so far is not very exciting. When we really check whether 
each polygon of the scene is shadowed by another polygon, complicated scenes 
will need a lot of computation time. To speed up the process, we use the same 
techniques as for the painter’s algorithm: 


By means of the object preprocessor, the faces of the scene are connected to 
primitives (objects, object groups, slices, etc.). Let a face belong to a primitive V; 
and another face belong to a primitive V2. When the bounding rectangles of 
and W, do not overlap, we do not have to check anything. When the rectangles 
overlap, and when the result of the priority test in the n-th light system is 
that WY, is closer to the light source L, than Wo, all the faces of V1 potentially 
cast shadows on all the faces of V2. If in such a case WV is convex, its outline 
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in the light system is convex, too. This means that we only have to clip the 
outline of @, with each face of Wz. This is the reason why scenes that consist 
only of convex primitives can be rendered with shadows without any major loss 
of speed. 





FIGURE 6. Several light sources illuminate convex polyhedra. 


Convex polyhedra have the convenient property that they cannot cast shadows 
on themselves (Figure 5). This is why the shadow-test does not have to be ap- 
plied to the other faces of the primitive the face belongs to. Non-convex polyhe- 
dra, however, may cast shadows on parts of themselves. The faces whose shadows 
can be seen must have their illuminated side turned to the viewer. (The viewer 
can see the illuminated side of a face when the projection center C and the light 


source L, are on the same side of the plane of the face, otherwise the face is 
“dark.” ) 


We have already dealt with important classes of non-convex polyhedra like func- 
tion graphs and approximations to surfaces of revolution. All these surfaces are 
at least split up into slices. These slices are separated by parallel planes o. The 
special separating plane o,,, which coincides with the light source L,, plays a 
similarly important role as the “critical planes” oo played for the hidden-surface 
algorithm in the Sections 5.2—5.4. If ® is a sliced surface and if o,, intersects ®, the 
two partial surfaces ®, and 2 on the different sides of o, cannot cast shadows 
on each other. A slice of a partial surface can only cast shadows on slices that 
are further away from o,,. The “critical slice” that connects ®; with ®2 may cast 


6.4 


Section 6.4. Reflections 177 


shadows on parts of any other slice. 


The slices consist of two types of faces, which are analogous to the frontfaces 
and backfaces in the screen system (Figure 4). 


The dot product of the normal vector of the face and the oriented light ray to 
the center of the face will be positive or zero for some faces and negative for 
others. Faces of the same type can be connected to “ribbons.” The ribbons can 
be sorted like in Section 5.3. Faces of the same ribbon will never cast shadows on 
each other because in the light system their projections cannot overlap (otherwise 
the ribbon would have been split up). A ribbon can only cast shadows on another 
ribbon when it is closer to the axis a, that is normal to the separating planes 
and that coincides with the light source. This is especially true for surfaces of 
revolution where each “ring” (Section 5.2) consists of one or two ribbons. 


Reflections 


Like shadows, reflections help to make spatial objects look more realistic. In com- 
bination with shadows, the effect is even more enhanced. However, this works 
only with a limited number of reflecting elements in a scene. Pictures with bounc- 
ing reflections are nice to look at and they are a test for really good algorithms 
(like ray tracing). On the other hand, such complicated images can be confusing. 


In this section, we will only talk about simple reflections, i.e., reflections on one or 
several reflecting faces that cannot produce bouncing reflections (for example, the 
faces of individual convex objects). We will not talk about reflections on curved 
surfaces or about bouncing reflections, since the calculation of such images takes a 
lot of CPU time. Reflections on single “mirrors,” however, can be done amazingly 
fast, provided that the scene consists of the primitives that are generated by our 


object preprocessor. In relation to the computation time, the quality of the result 
is satisfactory. 


Consider a scene of objects, where only one face is reflecting (Figure 7). The 
mirror plane pz separates the space into two halfspaces. All the objects of the scene 
that are completely at the reflecting side of the mirror, or that are intersected 
by the plane p, are potentially visible on the mirror’s face. 


We might also say that the imaginary object “doubles,” which we get when 
we reflect the objects at the plane yp, can be seen through a “window” (the 
transparent reflecting face R) from the projection center. 


Consequently, the painter’s algorithm can also be applied to the plotting of 
reflections. We plot the images of the faces of our scene in the above-mentioned 
order, until we have plotted the image of the reflecting face. Before we plot the 
rest of the image, we do the following: 


First we reflect all the objects that coincide (completely or partly) with the 
halfspace that is determined by the reflecting side of the mirror plane yz. When the 
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FIGURE 7. When we look into a mirror, we can see the “doubles” of our objects 
through the “mirror window.” 


scene is static (i.e., the objects remain in their relative positions), this calculation 
can be done before any drawings. Otherwise the “reflection pool” (where we store 
the coordinates of the reflected vertices) has to be recalculated for each frame. 


Among the reflected objects, we select those that can be seen through the mirror 
window R. We can check this with the help of bounding rectangles. (Do the 
bounding rectangles of the reflected objects overlap with the image R“ of the 
reflecting face R?) With convex objects, we can find out which position the 
outlines of the objects have with respect to the outline of the clipping window. 
By means of this test, we can find out which of the selected doubles are partly 
visible and which are completely visible. 


Now we sort the selected objects with the help of our priority test and then we 
plot them as usual, one after the other, according to the priority list. The images 
of the faces of objects that are only partly visible have to be clipped with the 
clipping window R°*. 


The shade of a reflected face is basically the same as that of the real face. The 
reflected face will appear a bit darker, however, because the light rays that are 
reflected from the original face make a detour over the mirror. (In all reflections 
the light rays are split up. In addition to that, the virtual distance from the 
viewer increases. ) 


This simplified shading model works fast and is satisfactory for many kinds of an- 
imations. Things get more complicated when the reflecting face itself illuminates 
the scene indirectly, i.e., with reflected light. (This occurs when its reflecting side 
is turned towards a light source and when the reflecting face is not in the shadow 
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of an object.) This kind of illumination is in fact the same as the illumination 
by an additional light source L*. Thus, if we plot a scene with reflections on a 
reflecting face, each light source that illuminates the reflecting side of the face R 
increases the number of light sources by one. 





FIGURE 8. The simplified shading model works very fast, especially for scenes with 
only one reflecting face. 


We get the coordinates of L* when we reflect the given light source L,. Of 
course, the intensity of the point source L* is less than the intensity of Ly 
(because reflections reduce the light intensity). Furthermore, the reflected light 
can only come through the mirror window R. 
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If we go one step further and calculate cast shadows, the reflected light may be 
additionally obscured by shadow polygons cast from the objects in front of the 
reflecting face, which will happen when the light comes from L,. We get the 
same shadow polygons when we cast shadows from the object doubles and when 
the light comes from D*. Consequently, we may say that the reflected light is 
additionally obscured by the reflected objects. 


These considerations show that difficulties will increase dramatically when we 
have several reflecting faces. As long as the faces are in such a position as to not 
allow any bouncing reflections, the simplified shading model (Figure 8) works 
fine (and comparatively fast). We plot the scene one face after the other. Every 
time we plot a reflecting face, we paint the corresponding reflected scene on it. 
Once we calculate shadows, however, each reflecting face that is turned towards 
an existing light source will produce a new light source. Therefore, we should 
leave such complicated scenes to really sophisticated programs like ray tracing. 


Patterns 


Consider an object with patterns like the one in either Figure 6 or Figure 9. The 
patterns are polygons painted on different faces. Of course, it would not be wise 
to declare these polygons as objects in their own right. In this case, the computer 
might have trouble with the priority list because the patterns touch the object. 
In addition to that, the number of objects would increase, so that the processing 
would be slowed down unnecessarily. 


For this reason, we combine each pattern with the corresponding face. After the 
face has been plotted, its patterns are added. A face can have any number of 
patterns. The patterns should be split into convex polygons. 


If we want to add shadows, we first plot the shadows on the face. The images 
of the shadow polygons of different degree (Section 6.3) are stored temporarily. 
Then we plot the patterns in the following way: If the whole face is “dark” (i.e., 
if it is a backface in all the light systems), all its patterns can be plotted in a 
darker shade. If the face is lit by at least one light source, we clip the images 
of all the patterns with the precalculated shadows of different degree (starting 
with degree 1). 


This method is very efficient in terms of computation time. In general, we can 
say that the number of patterns has much less influence on the CPU time than 
the number of faces. 


General patterns (polygons) can be described by two-dimensional coordinates in 
a data file (Figure 10): 


CUBE gray box voll 10 10 10 
patterns face 1 polygon LEFT white -1-1, 1-1, 11 
face 2 polygon FRONT yellow -2 -2, 2 -2, 2 2, -2 2 
face 3 polygon RIGHT black -3 -3, 3 -3, 3 3 
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FIGURE 9. Patterns on the faces of an object can be a nice feature. Computation 
times increase only a little. 
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FIGURE 10. Cube with patterns. 


face 4 polygon BACK red “4 -4,4-4, 44, -44 
face 6 polygon TOP1 cyan -2 -2, 2 -2, 22, -2 2 
polygon TOP2 black 00, 40, 44, 04 


In the sample data files on your disk, you can find several other examples for 
patterns. 


6.6 Retraction, ‘Transparent Objects 


In Section 6.4, we saw that the painter’s algorithm can be applied successfully 
to a simplified reflection model. On the other hand, we had to realize that when 
we include shadows the fast algorithms soon reach their limits. 


The same is true for transparency models. Usually, the images of transparent 
polyhedra or transparent solids with curved surfaces are drawn by ray tracing 
programs. Such programs work perfectly for the calculation of refractions on 
transparent material because they trace both the projection rays and the light 
rays. 
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FIGURE 11. The refraction of light rays on parallel plane surfaces. 


In this section, we will show that the painter’s algorithm can still produce ac- 
ceptable results (at least for computer animations) for transparent plane surfaces 
and transparent solid polyhedra. This simplified model can easily be extended 
to single reflections and shadows. 
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Figure 11 illustrates that the refraction of light rays on a transparent material 
with parallel surfaces depends on the angle of incidence a, as well as on the 
thickness a and the kind of the material given by a constant c for the refraction, 
which is given by 


sin a 


C= ‘sin B : (3) 
For very thin material, the refraction is even negligible. 


To solve the problem we can use the following trick. We plot our scene face 
by face. Whenever a face is transparent (and not colorless), we do not fill the 
polygon completely, but we set only every second (third, fourth) pixel. This 
implies that the face will be slightly visible in its given color. On the other hand, 
the background color is only partly erased and will “shine through.” The better 
the screen resolution is, the closer the pixels will stick together. Thus, for the 
human eye, the different colors will more or less melt together to a new color. 
(This trick is also used in various printing techniques.) 


When we plot the shadow of a transparent face, we do not fill the shadow poly- 
gon with a darker shade of the color of the obscured face, but we set every 
second (third, fourth) pixel in a darker shade of the color of the transparent 
face. Moreover, the shadow polygons of the transparent faces have to be drawn 
after the “normal” shadows! (In fact, the pixels that are filled with the color of 
the transparent face are not shadows but illuminated spots, which must not be 
erased!). 


Once we deal with transparent solid polyhedra © (prisms, pyramids, etc.), re- 

fractions have to be taken into account. In this case, we refract the projection 

rays through the vertices of the transparent frontfaces F;. This leads to new 

polygons F€ in the image plane. The intersections of F; with the image poly- 

gon of © are polygons R;. All the faces the image polygons of that intersect R; 

are subject to refraction. We calculate their intersection polygons {I,,} with Rj. 

Now we start to plot our scene. When we come to the transparent polyhedron ®, 

we do the following: 

e We paint the contour polygon of © in the background color. 

e We calculate all the intersection polygons {I;,} and refract them inversely. 

e We fill these polygons with a shade that is a bit darker than that of the 
corresponding faces. 

@ When the material the polyhedron © consists of is not colorless, we plot the 
frontfaces of © as transparent faces. 


A simple application is illustrated in Figure 12. The inversion of the refraction 
can be solved using 3 (c = 4/3) as follows (Figure 11): 
Because of z = QQ = PP we have 


sin a 
a(tana— tan) = a (tana — 7>———=) = pa tana — pr. (4) 
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FIGURE 12. A swimming pool with constant depth from two different point of views. 
This leads to the trancendent implicit equation 


asin a 
f(a)= (p2 — a) tana+ Ja sina —pl=0. (5) 


When the projection center is outside the water (pz > a, =? <a < 5), the only 
real solution of this equation can be found by means of NEWTON’s iteration 
(see Section 8.2). 


7.1 
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Hidden-Line Removal 


For technical drawings and publications, we often have to produce line drawings, 
mainly because they are easier to handle and to reproduce. Sometimes it is also 
easier to demonstrate specific facts by means of line drawings than by means 
of painted images. For this reason, we dedicate this chapter to the removal of 
hidden lines. We will distinguish between algorithms that are screen-oriented 
and algorithms that can be used for plotter drawings. 


A Quick Screen-Oriented Method 


In Chapter 5, we talked about a fast hidden-surface algorithm: the painter’s 
algorithm. This algorithm can also be used for the quick removal of hidden lines. 
When we plot the image of a scene, we do not fill the images of the faces with 
the color of the faces but with the color of the background. In this manner, the 
image polygons of the faces are erased. Immediately after an image polygon has 
been erased, we redraw its outline and, if necessary, other lines (like the outlines 
of patterns) in the color of the face. 


The adapted painter’s algorithm works efficiently and removes hidden lines very 
fast, especially when we deal with objects, the images of which can easily be 
rendered by a simple shading model. (In addition to objects with convex outlines, 
these are the surfaces of revolution, function graphs and sliced surfaces like in 
Chapter 5). 


Since this method is screen-oriented, it can be used to make hard copies or 
photographs from the screen. If your screen has a good resolution (in Figure 1 the 
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resolution is 1280 x 1024), this poses no problems. For lower screen resolutions we 
will either use algorithms that can be used for plotter drawings! or we will create 
Postscript images that work in the same manner as the painter’s algorithm. 





FIGURE 1. The adapted painter’s algorithm removes hidden lines very quickly, but is 


dependent on the screen resolution. However, it is perfectly suited to create PostScript 
files. 


Hidden-Line Removal on Objects with Convex Outlines 


As for almost every application in computer graphics, convex objects play an im- 
portant part in the speed of a graphics program: convex polyhedra are perfectly 
suitable for fast and precise hidden-line removal. 


Let a scene consist only of convex (solid) polyhedra. Let the priority list of the 
objects be already determined (Section 5.6). Now we plot the images of the edges 
of the individual objects. (We may plot the objects from the back to the front, 
according to the priority list, although this is not necessary.) Instead of filling 
the images of the frontfaces, we only plot their outlines and — if necessary — other 
lines on them like the outlines of patterns. 


Each line PQ in a frontface is potentially visible, because the whole frontface is 
locally visible (Section 5.1). However, it can be partly or completely hidden by 
the convex outlines of the images of the other objects, which may obscure the 


“With the appropriate software, the drawings can also be done by printers, 


especially by laser printers like the illustrations in this book. In this case, the 
accuracy of the image is not dependent on the screen resolution! 
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the- convex outlines of the images of the other objects, which may obscure the 
object according to the priority list (Figure 2). 


In order to find out whether the outline Of of the k-th object obscures P°Q* we 
can check whether or not the bounding rectangles of the image line P°Q¢ and 
of Of overlap. If the rectangles overlap, we try to intersect P°Q¢ with Of. When 
we get two intersection points S;,, and S;,, we store the parameters ,,, Ax,, 
which lead to their position vectors 3,, and 3%, (Ski = p® +Ani(q¢ — p°)). We 
sort the parameters (A,;, < A,,) and modify them by 








0, if Ax; < 0 (> he P); | 
Ati = 4 Ani, if O< AG < 1; (4 = 1,2). (1) 
1, if Aki > 1 (=> Sei = Q); 
If Ax, = 0 and %, = 1, the edge is completely hidden and we can turn to the 
next image line. Otherwise the “zone” [Ax,, Ax] on P°Q¢ is hidden. 
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FIGURE 2. The image of the edge of a convex object can only be hidden by the 
outlines of other polyhedra. Note that the primitives do not intersect, even if it looks 
as if they did. 


Here is the C code for the determination of the hidden zones for convex objects: 


[eo a a ee eee 
void invisible_zones(k, zones, p, q, obj) (— Proto.h) 
short +k; /* Number of zones. */ 
Vector2 zones[ |; /* Has to be allocated outside the function. */ 
register Vector p, q; /* The vertices of the edge. */ 
Polyhedron + obj; /* The object the edge belongs to. */ 
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register Polyhedron *o0bj2 = Object-_pool, 
* hi.obj2 = obj2 + Total_objects; 
Vector min, maz; | 
short i, n; 
register Vector2 * zone = zones; 
Vector +#*poly; 
float z[2]; /* Dummy. «/ 


/* Bounding box of edge. */— 
for (i= 0; i< 3; i++) 
if (qt) < pli]) mini] = lt], maz[i] = pili); 
else mini] = pli], maz[i] = q[4]; 
/* Clip with the outlines of all the other objects. */ 
for (; 0bj2 < hi_obj2; 0bj2++) { 
if (obj >priority[SCREEN_SY ST]||0bj2—>indez] != 0bj2—>indez) 
continue; 
if (!overlap((Vector *) min, (Vector *) maz, 
0bj2—>box_min, 0bj2—>box_maz)) continue; 
n = 0bj2->size_of -contour|SCREEN-_SY ST}; 
poly = obj2—>contour|[SCREEN_SY ST}; 
if (!segment_cuts_poly(zone, p, q, n, poly)) { 
if (inside_poly(p, n, poly, SCREEN_SYST, z)) 
return ; /* Completely hidden. +/ 
else continue; 


/* Modify zone. */ 
for (i= 0; 1< 2; i++) { 
if ((*zone)[i] < EPS) (*zone)[i] = 0; 
else if ((«zone)[i] > (1— EPS)) (*zone)[i] = 


if ((*zone)[(0] == 0 && («zone)[1] == 
*k = 0;return; /* Completely hidden! */ 


} 
else if ((*zone)[0] < \szoneMt) zone++; 
} /* end for (0bj2) */ 
*k = zone — zones; 
}  /* end invisible.zones() */ 


The function segment_cuts_poly() calculates the parameter values to the inter- 
section points of an edge with a convex polyhedron. If the edge is completely out 
of or completely inside the polygon, the function returns FALSE, else it returns 
TRUE. 
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P| 
Bool segment_cuts_poly(lambda, p, q, k, poly) (— Proto.h) 
float lambda| |; 
Vector p, q; 
short k; 


Vector *«poly; 


{ /* begin segment.cuts_poly() */ 
register Vector «a = poly, *#b = a+1, **hi_poly = a+k; 
short n = 0; 
float t1, £2; 
float temp; 


while (a < hi_poly) { 
if (6 == hi-poly) b= poly; 
if (intersect_segments(&t1, &t2, p, q, a, **b)) { 
if (2 >= 0&& t2 <= 1) { 
lambda[n++] = 11; 
if (n == 2) 
if (fabs((double) lambda[0] — lambda[1]) < EPS) 
return FALSE; 
if (lambda[0| > lambdali)) 
Swap (lambda|0), lambda[1]); 
return TRUE; 
} /* end if (n) */ 
} /* end if (£2) */ 
} /* end if (intersect) */ 
a++; b++; 
} /* end while (a) */ 
return FALSE: 
} /* end segment.cuts_poly() */ 


After having calculated n hidden zones on P°Q¢ we have to determine which 
zones of P°()¢ are still visible. If no hidden zones were found (n = 0), P°Q€® is not 
obscured at all. If only one hidden zone was found (n = 1), the edges given by 
the parameter intervals [0, Ax,] (if Ax, > 0) and [Ax,, 1] (if Ax, < 1) are visible. 
For n > 1, we have to sort the zones as follows (Figure 3): 





Let p41 and pg be the parameter values that lead to a visible zone. We let 1 = 0 
and start a loop: 


First, for all the hidden zones, we check whether jz; is inside a hidden zone. If 
this is the case, we transfer the beginning of the visible zone to the end of the 
hidden zone: 


Nk, < pa < Ake => [1 = rx, (k=1,...,n). (2) 
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Now we come to pz. We start with 2 = 1 and, for all the hidden zones, check 
whether jl2 is inside a hidden zone. If this is the case, we transfer pig to the 
beginning of the respective zone: 


Ak, < 2 Ak. => Ha = Ak, (k =1,...,n). (3) 


Now we plot the part of P°Q¢ that is given by the interval [u, 2]. To enhance 
the three-dimensional aspect of the image, it is a good idea to shorten the line 
“a little bit,” if 4; is not O or 1 (Figure 4). At the same time, we store the upper 
limit of the zone to = Ax, of the hidden zone. 





FIGURE 3. How to get the visible zones on the image of an edge. 


For the next visible zone, we let 1 = po. If 41 = 1, we are finished, otherwise 
we have to reenter the loop. 


The corresponding C code looks like this: 


[ 7 SS 
void plot_visible_zones(p, q, n, pool) (— Proto.h) 
Vector p, q; /* The line segment (screen coordinates). */ 
short n; /* Number of hidden zones. */ 
Vector2 pool| |; /* mn hidden zones. */ 


By approximately the size of a pixel. Because we do not think in terms of 
screen resolution, it is better to say: to shorten the line by a constant length s 
that is approximately 1% to 2% of the total diameter of the image of the scene. 
For really perfect images, we better create an “aura” of constant width s around 
the visible objects by enlarging the outlines @f like in Figure 4. This shortens 
the lines automatically. 
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FIGURE 4. Objects with an “aura.” 


{ /* begin plot_visible_zones() */ 
Vector a, b, pq; 
Vector2 *lambda = pool, *hilambda = lambda + n; 
register float m1, m2, t_help; 
Bool go_up, go.down,; 


if (n == 0) { /* No hidden zones. «/ 
draw-line(p, q); 
return ; 


if (n == 1) { 
/* One Ga zone and, therefore, up to two visible zones. */ 
Subt_vec(pq, p, q); 
if ((ml = (xiambda)|0}) > 0) 
Linear_comb(a, p, pq, m1), 
draw-_line(a, p); 
if ((m2 = («lambdla)(1]) < 1) 
Linear_comb(b, p, pq, m2), 
draw-_line(b, q); 
return ; 
} /* end if (n == 1) */ 
Subt_vec(pq, p, 4); 
thelp = 0; 
do { 
m1 = thelp; /* Determine lower parameter m1. */ 
do { 
goup = FALSE; 
for (lambda = pool; lambda < hitambda; lambda + +) 
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if ((*lambda)[0] <= m1 8&& (*lambda)(1] > m1) { 
m1 = (*lambda)[1] + EPS; goup = TRUE; 


} 
} while (go_up); 
m2 = 1; /* Determine upper parameter m2. +*/ 
do { 
godown = FALSE; 
for (lambda = pool; lambda < hiJtambda; lambda + +) { 
if ((*lambda)[0] > m1 && (+*lambda)(0| < m2) { 
m2 = (xlambda)|0| - EPS; go.down = TRUE; 
thelp = (*lambda)(1); 


} /* end for (lambda) */ 
} while (go_down); 
if (m2 —ml1 > EPS) { /* Draw segment from m1 to m2. */ 
Linear_comb(a, p, pq, m1); 
Linear_comb(b, p, pq, m2); 
if (ml > EPS && m2 < (1 — EPS)) 
draw_line(a, 5); 
else if (ml > EPS) 
draw-_line(a, b); 
else if (m2 < (1 — EPS)) 
draw-_line(b, a); 
} /* end if (m2 — m1) +*/ 
} while (m2 < (1 — EPS)); 
}  /«* end plot_visible_zones() */ 


In which order do we draw the images of the edges? When we plot them according 
to the edge list, we first have to eliminate the edges on the backfaces, which is 
not always easy. Therefore, it is best to plot the edges as sides of the faces. (We 
know the drawing order of the faces.) 


We only have to make sure that we do not plot the images of some edges twice 
because an edge is always the intersection line of two faces. (The only edges, 
the images of which will never be plotted twice, are the contour edges, because 
they are the intersection lines of a frontface and a backface, and we ignore the 
backfaces. ) 


One idea to prevent double drawing is the following: let ® be the object, the image 
of which we intend to plot. Now we copy the edge list of © into a temporary 
table. Before we draw the image P°Q¢ of an edge PQ, we check whether we can 
find the edge PQ (or QP) in the table. When we can find it, we plot P°Q<¢ and 
eliminate the edge PQ from the temporary table. 





When we remove the frontface of a convex polyhedron ©, we can look into the 
polyhedron. In this case, we also have to check the edges on the back of ®, to 
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removed frontface Cea 


FIGURE 5. How to modify hidden zones when they are overlapped by the image of 
a removed frontface. 


clip their images with all the outlines of the other objects that obscure ® and to 
intersect the hidden zones S;,5;, with the image F° of the removed frontface. 
Whenever a hidden zone is overlapped by the polygon F°, it has to be modified 
or even to be split into two zones (Figure 5). 





When we remove more than one face of ®, things get more complicated. First, 
we have to modify all the hidden zones by means of the images of all the re- 
moved frontfaces. Secondly, it may be possible that we can “look through” the 
polyhedron. To find out whether this is the case, we do the following (Figure 6): 


e If all the removed faces are backfaces, the object can be treated like a convex 
object. 


e If all the removed faces are frontfaces, we cannot look through the poly- 
hedron. In this case, we can treat the object like a convex object when we 
compare it with the other objects. 


e If there are frontfaces and backfaces among the removed faces, we clip the 
image of each removed backface with the images of all the removed front- 
faces. Thus, we get a set {S;} of (mostly convex) intersection polygons 
through which we can look through the polyhedron. If this set is empty, 
there is no “hole” in the image of ®. If it is not empty, we have to store it 
as a part of the outline of ®. 


If the image of ® has holes (given by the set {.5;} of convex polygons), we 
have to modify the hidden zones that are produced by the convex outline 
of the image of ® like in Figure 6. 
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FIGURE 6. How to check whether we can look through a polyhedron with convex 
outline. : 


As we can see, the precise hidden-line algorithm for objects with convex outlines 
is still reasonably fast, even if the objects are hollow. 


Depth Buffering for Visibility 


In Chapters 5 and 6, we described a rendering algorithm that works very ef- 
ficiently for scenes that consist of non-intersecting primitives with convex out- 
lines. Admittedly, it is sometimes hard to split scenes in this way (even though 
in many cases it is worthwhile! ). In the previous sections, we discussed a special 
hidden-line algorithm. In this section, we will develop a screen-oriented rendering 
algorithm that works for any kind of objects. 


Two major advantages of the following algorithm are that it is easy to implement 
and it works comparatively fast. A disadvantage, however, is that in its genuine 
implementation, it needs a lot of memory (up to several Megabytes), which makes 
it necessary to split the scenes up in a certain way — at the cost of computation 
time. 





The scene is interpreted as a set of polygons (it is of no importance to which 
objects the polygons belong*). Each polygon P has a picture P* on the image 
plane a (the screen). We apply the linear transformation T, : P(x, y, z) > 


3However, to be able to apply “backface removal” we should know whether 
the polygon we are plotting is the face of a convex polyhedron or not. 
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P*(a* = 2, y* = y, z* = z/(d—2z)) of Section 2.3 to all the vertices of the 
polygons. If we project the new set of polygons orthogonally from the infinite 
point of the positive z* — axis onto the image plane, we will get the genuine 
image of our scene again (Figure 7). 


Now consider a grid [0, M — 1] x [0, N — 1] that is placed over the screen. We 
initialize each field value of a two-dimensional array Zbuf|M]|N] by the smallest 
z*-value. Then we “buffer” each polygon of the scene in the following way: for 
each grid point X°(i, j) at the inside of the image polygon P° = P*°, we have 
a space point X* on the normal to the projection plane 7 on the plane of P”. 
This “depth” z* is stored if and only if z* > Zbuf|i]|j]. By doing this for each 
polygon of the scene, we store the visible parts of our polygons. 





polygon of image polygon 
a i | oan Nl i * 7 >~ i 


the scene 


transt{or! ned 


polygon 


FIGURE 7. Depth buffering. 


At any time of the rendering of the scene, the visibility test is simple: an arbitrary 
space point P(x, y, z) is visible (at the moment when the image pixel is drawn) 
if and only if the corresponding field value contains the value z* = z/(d — z) (+ 
a certain tolerance, depending on the width of the grid). 


In the simplest case, the grid dimensions M and N are the dimensions of 
the screen (measured in pixels). Then a point P(z, y, z) corresponds to the 
field value Zbuf|[round(x)|[round(y)]. If we want to have control over the two- 
dimensional field of float variables, we need 4M N bytes, ie., 3 Megabytes for 
a screen with a resolution of 1024 x 768 or 1 Megabyte for a screen with a res- 
olution of 640 x 400! Because we have to admit a certain tolerance anyway, it 
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will be enough to store the z*—values as short numbers, where we assign the 
smallest z*-value to 0 and the greatest z*-value to the largest unsigned short 
number (~ 65000). This reduces the necessary memory to 50% (2M N bytes). 


As long as we have enough RAM memory at our disposal, we prefer this kind 
of storage. Otherwise, we divide the screen into several horizontal zones and 
display the scene in several steps — at the cost of computation time, because 
many polygons will have to be proceeded two or even more times if they overlap 
two or more zones.4 


The allocation and the freeing of the two-dimensional grid can be done by a 
function 


#-define Alloc_huge_2d_array(type, array, n, m) {° \ (— Macros.h) 


array = (type **) mem.alloc(n, sizeof(type *), "pointers");\ 
for (i =0; i<n; i++)\ 
array|i] = (type *) mem-alloc(m, sizeof(type), "2D-array");\ 


typedef unsigned short Ushort; (— Types.h) 
Ushort Init(+ * Zbuf, NULL), 

Init(Maz_z_grid, 100), Init(Maz_y_grid, 50); (— Globals.h) 
Bool Init(Z_buffering, FALSE); (— Globals.h) 
Global Init_fptr(move_scan, quickmove); (— Proto.h) 
Global Init_fptr(draw_scan, quickdraw); (— Proto.h) 
TP] 
void z_buf fer(on) (— Proto.h) 

Bool on; 


{ /« begin z_buf fer() */ 
register short 7; 


Z buf fering = on; 
if (on) { 
move.scan = move_buf fer; 
draw.scan = quick_draw-_buf fer; 
Maz.sz_grid = Mars —Min«z + 1; 
Maz.ygrid = Mary —Miny + 1; 
if (Zbuf == NULL) 
Alloc_huge.2d_array(Ushort, Zbuf, Maz_y_grid, Maz_z_grid) ; 


“In an extreme case, each line of the screen can be considered as a zone. 
Usually this is done in connection with scan-line algorithms [FOLE90]. 

5In Chapter 3, we developed a very similar macro Alloc_2d_array(type, array, 
n, m). This macro allocates memory allocation all the space for the array at 
the same time. On computers with less memory, this might cause an “out of 
memory error,” even though there is enough memory left. Thus, we split the 
memory into n sectors. This will have no influence on the access to the variable 
Zbufii|[j], which is transformed into the expression +*(*(Zbuf + 7) + j) by the 
compiler. 
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selse { 
move_scan = quick_move, draw_scan = quick_scan; 
Free_huge_2d_array(Zbuf, Maz-_y-grid); Zbuf = NULL; 


} 
} /* end zbuf fer() */ 


(The functions move_buf fer() and quick_draw_buf fer() will be developed later 
on.) The initialization of the array is done by the function 


void clear_z_buf fer() (— Proto.h) 


{ /« begin clear_z_buf fer() */ 
register Ushort +* grid, *hi_grid, 1; 


if (!Zbuf) safe_exit("Use z_buffer(TRUE) first"); 
for (i= 0; i< Maz-_y-grid; i++) { 
higrid = (grid = Zbuf{t|]) + Maz_z-grid; 
while (grid < hi-grid) 
xgrid++ = 0; 


} 
} /* end clear_z_buf fer() */ 


When we proceed a polygon, we first clip it with the clip volume (Section 2.5). 
The clipped polygon is then proceeded as usual. At the end of the function 
poly_move() (Section 4.6), we add the lines 
if (Z_buf fering) 
set_plane_point(0, a); 


and at the end of the function poly_draw() (Section 4.6), we add the lines 
if (Z_buf fering && Cur-vitz — Vtzx < 3) 
set_plane_point(i, a); 


The function set_plane_point() transforms the z-value of the point a to the inter- 
val 0 < Zirans < 21° = 65536, i.e., to the range of an unsigned short number. 
When it comes to the third point, we can determine the constants of the plane 
of the polygon: 


Plane Buffered_plane; (— Globals.h) 


#-define Float.to_Ushort(u, f)\ (— Macros .h) 
u = 1000 + 64000 * (f — Min.z) / (Mazz — Min.z) 
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void set_plane_point(i, p) (— Proto.h) 
short 7; 
Vector p; 

{ /* begin set_plane_point() */ 
static Vector tri[3]; 


if (ij > 2) return ; 
Copy-vec2(tri[i], p); 
/* Transform the z-value into the range of a Ushort. */ 
Float_to.Ushort(tri[i][Z], p[Z]); 
if (i == 2) 
plane_constants(& Buf fered_plane, tri[0|, tri[1], tri[2]); 
} /* end set_plane_point() */ 


With the help of the plane constants, we can determine the z*-values of all points 
in the polygon’s plane by means of the routine 


float z_value(z, y) (— Proto.h) 
short 2, 4; 


{ /* begin z_value() */ 
static float +d = &Buf fered_plane.cnst, 
*a = &Buf fered_plane.normal[X], 
*b = &Buf fered_plane.normal[Y], 
c= &Buf fered_plane.normal[Z]; 
return (*d —*a *x — +b xy) / (*c+ EPS); 
} /* end z_value() */ 


(The EPS helps to avoid a division by zero.) 


Now we can write the desired functions 
move_buf fer() and quick_draw-buf fer(): 


short X1_grid, Y1_grid; (— Globals.h) 


void move_buf fer(xz, y) (— Proto.h) 
register short 2, y; 


{ /* begin move_buf fer() */ 
Xlgrid = 2; 
Yl.grid = y; 

} /* end move_buf fer() */ 
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a 
void quick.draw_buf fer(zx, y) (— Proto.h) 
register short 7, y; 


{ /« begin quick_draw buf fer() */ 
register short 21 = X1-grid; 
float z1, dz; 
register Ushort «zg = &Zbufly — Min_y][X1-grid — Min_z]; 


zl = z.value(X1-_grid, y); 
dz = (x!= 21) ? ((z-value(z, y) — z1) /(2 —21)) : 1; 
for (; 21 <= 2; z1++4+, z21+= dz, rg++) { 
if («rg < 21) 
7g = 21, 
G_set_pizel(z1, y); 
} /* end for (x1) */ 
Al.grid = g; 
} /* end quick_draw_buf fer() */ 


To display the scene, we now use the function 


void buf fer_scene() (— Proto.h) 
{ /* begin buf fer_scene() */ 
short maz_zones = 4; 


/* If you have enough RAM, let mazx_zones = 1; */ 
float h = Window-height; 
float yl, y2, yO = (short ) (h) /maz_zones; 


for (yl = 0, y2 = yO; yl < hj yl += yO, y2+= yO) { 
z_-buf fer(FALSE); 
zy-region(0.0, Window_width, yl, Minimum(y2, h)); 
z-buf fer( TRUE); 
clear_z_buf fer(); 
< plot all the polygons of the scene in an arbitrary order > 
} /* end for (y1) */ 
G_swap-screens(); 


} /* end buf fer_scene() */ 


and we let display_scene = buf fer_scene; 


For a general hidden-line removal, we still need a general function draw_buf fered 


ine(), which connects two space points: 
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void draw_buf fered_line(p, q) 


{ 


} 


Vector p0, 0; 


/* begin draw_buf fered_line() */ 
Vector p, q, delta; 
short i, 20; 
float ¢; 
register short z, y; 
Ushort ¥*z; 
Vector g; 
Bool ezists; 
if (!clip3d_line(&ezists, p, g, p0, g0)) { 
Copy-vec(p, p0); Copy-vec(q, 90) ; 
} else if (!ezvists) return; 
Float_to.Ushort(p|[Z], p0[Z]); 
Float_to.Ushort(q|Z], q0[Z}); 
i0 = Mazximum(fabs(q[X] — p[X]), fabs(g[Y] — p[Y])); 
if (20) { 
z= p(X] + 0.5; y= p[Y] + 0.5; 
z= &Z_buffer.val[y — Min_y|[x — Min_a]; 
t= Marimum(p[Z}, a[Z1); 
if (xz <= t) { 
*Z= 1; 
G_set_pizel( x, y); 


return; 


} 
Subt_vec( delta, p, q); 
Scale_vec( delta, delta, t); 
Copy-vec(g, p); 
for (i = 0; i <= 10; i++) { 
z= g(X]; y= 9 [Y]; 
z= &Z_buffer.val|y — Min_y|[z — Min_a]; 
if (+z <= g[Z]) { 
«z= g[Z]; 


G_set_pizel(2, y); 
} 
Add_vec(g, g, delta) ; 


} 
/* end draw_buf fered_line() */ 


(— Proto.h) 


8 


Mathematical Curves and Surfaces 


In Chapters 8 and 9, we will talk about mathematical curves and surfaces and 
— as an approximation to them - spline curves and spline surfaces. Sometimes it 
is better to have line drawings as an output. The drawn images of such curves 
further support the human imagination, especially when we talk about the lines 
of intersection of such surfaces. For scientific purposes, the line of intersection is 
often of much more interest than the rest of the image. 


If we want to draw the image of a surface by hand or with the plotter, we do it by 
drawing the images of curves on the surface, especially the parameter lines and 
the contour lines. These and, of course, many other curves on surfaces as well 
have always been of great interest to geometrists. With the help of computers, 
today we are able to do things that in the past would have meant a lot of 
work. This is especially true for the calculation of surfaces that are known only 
approximatively, which means that only a limited number of points on the surface 
are given. 


Of course, from the geometrist’s point of view, it is interesting and often neces- 
sary to approximate surfaces bit by bit with the help of mathematically seizable 
surfaces (spline surfaces). This is what is normally done and the results are by no 
means unsatisfactory. However, the price that has to be paid for interpolations 
of this kind are comparatively long periods of calculation. Furthermore, every 
interpolation is only a guess. This means that even though in some cases we get 
pictures that look perfect, they do not necessarily correspond to reality. One only 
has to think of a landscape, the shape of which can be completely arbitrary. In 
a reversal of this train of thought, one can approximate surfaces with the help 
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of polyhedra. In this case, the computer does not have to distinguish between 
mathematically defined or empirically seizable surfaces. Certain kinds of prob- 
lems, and intersections in particular, can be solved much more easily this way. 
Also, many fast algorithms for the rendering of certain types of polyhedra even 
permit an animation of the picture of the surface. An approximation by poly- 
hedra may pose problems, particularly when one is forced to come back to the 
second differential form of the surface. In that case, a reasonable representation 
of osculating lines or lines of curvature without the use of mathematical formu- 
las is simply impossible. Therefore, we want to discuss both kinds of surfaces, 
however, with an emphasis put on approximational polyhedra. 


Parametrized Curves 


A “mathematical curve” is a (planar or not planar) line in space. In our context, 
we will only talk about curves in 3D-space (a curve in 2D-space can be interpreted 
as a curve in 3D-space, where the third coordinate vanishes). If such a curve is 
given by a parametrized equation 


== Z(u) = | y(u) with wu € [uy, us| (1) 


(where z(u), y(u), z(w) are arbitrary functions in the parameter u), it is quite 
easy to plot its image. We calculate a certain number n of space points, which 
belong to n different u-values, and submit their coordinates to a perspective or 
orthogonal projection. Then the image points are connected to a polygon that 
approximates the image of the curve. The number n of points depends on the 
application, but the more points we calculate, the better the approximation will 
be. 


Example 1: The straight line is the simplest curve in space: 


Pz t+ UQz 
E=| pytug |, uc Rk. (2) 
Pz +Uqz 


P(pz, Py; Pz) is a point on the line, (gz, dy, z) is the direction vector. With 
straight lines, we can generate ruled surfaces like the ones shown in Figures 
5, 6 and 7. 


Example 2: A circle in 3D-space with the radius r, the center M(mz, m,, mz) 
and the normalized direction @ = (az, ay, az) of its axis can be described 


by 


Mz — £(ay cosu + az, sin uv) 


Z= | m,+ t(az,cosu—aya,zsinu) | with s= ,/ a2 + a2, ué (0, 27]. (3) 
m, +rssinu 
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or 


Mz +17 COS U 
Z={| my,t+rsinu } we (0, 2z], (4) 
Mz 


when the axis is parallel z (a, = a, = 0). 


Such circles can be used to generate tubular surfaces like the ones shown in 
Figures 5, 6 and 7. 


Example 3: A loxodrome on a sphere (center O, radius r) that intersects 
all the meridian circles of the sphere at the constant angle a (Figure 1) is 
described by 


ssint cos u Or 
Z= | ssintsinu | with s = —————., ¢t = arctane"°*®, ue R.(5) 


2u cota’ 
scost—r vit+e 





FIGURE 1. Loxodrome on a sphere. 


Example 4: The line of intersection of two cylinders 
g* +y? =r and (x — a)? + 2? = 8” (a> 0) 
(Figure 2) can be parametrized as follows: 
1. For s < r —a, the curve is split into two branches. One of them has 
the representation 


a+ scosu 
I= r2—(a+scosu)? }|, ué (0,2z], (6) 
ssin u 


the other one is symmetrical to the xz-plane. 
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2. The case s > r +a (two branches as well) is covered by 


T COS U 

f= rsin u , wé (0, 2z]. (7) 
s* — (rcosu — a)? 

(The other branch of the line is symmetrical to the zy-plane.) 


3. In the third case (s € [r—a,r+a]), the line of intersection is continuous 
and a possible parametric representation is 


t(u) 
z= +,/r2 — t(u)? (< 0 if u € [2z, 4z]) , we [0,47]. (8) 
+./s* — (t(u) — a)? (< Otf u < [z, 3z]) 
The function 
1 
t(u) = gitts—at (r —s+a)cosul 
guarantees that all the coordinates are real (¢ € [a—s,r]) and that the points 


on the curve are distributed homogeneously. Figure 2 shows the limiting case 
s =r —a (treated as case 3). 


\ 
nites 


LY) 


a 


FIGURE 2. The line of intersection of two cylinders. 


Other examples of parametrized curves can be derived from Equations 10 
to 14 if u is constant and if v varies. 


In practice, however, there are many cases in which curves are not given by a 
parametrized equation. As a matter of fact, many curves are seen in connection 
with the surfaces they lie on. This is not so amazing when we consider that on 
every surface there are oo” lines (on a line there are “only” oo! points). 
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8.2 Classes of Parametrized Surfaces 


Analogously to Equation 1, a “mathematical surface” can be given by a 
parametrized equation 


x(u, v) 
£=Z(u, v) = As with wu € [uy, ua], u € (v1, val. (9) 


For v = const, we get the so-called u-lines, and for u = const, we get the v-lines 
as the simplest curves on the surface. 


Let ro(u)(u), yo(u)(u), zo(u)(u) be the parametric representation of a line g in 
space (u € [u1, ueg]). This “generating line” can now be submitted to arbitrary 
transformations in order to generate a surface. (A parametrized equation < = 
Z(t) of a general curve on the surface is defined by the functions u = u(t), v = 


v(t).) 


Example 1: Translation surfaces. The simplest way of generating a surface 
is to translate g along a line h (Figure 3) with the parametric representa- 
tion Zo(v), Yo(v), Zo(v) (v € [v1, ve]). Such a “translation surface” has the 
equation 


ro(u) + Lo(v) 
yo(u) +Yo(v) |. (10) 
zo(u) + Zo(v) 


£(u, v) 





FIGURE 3. The hyperbolic paraboloid as a translation surface. 
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Example 2: Surfaces of revolution. When the generating line g is rotated 
about an axis a, we get a surface of revolution (Figure 4). When a is the 
z-axis, the general equation of such a surface is 


Zo(u) cosu — yo(w) sinv 
E(u, v) = | zo(u) sinv ; = COS U v € (0, 27]. (11) 
Z0\U 


When g is planar and when its plane contains the axis a (e.g., for yo(u) = 
0), g is also called the “meridian line.” 


Fangs 
Nog SSP ee 
STN iar 


igs WANNA 
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FIGURE 4. Surfaces of revolution: the surface on the left is a hyperboloid with a 
straight generating line. The surface on the right has a generating helix, and surpris- 
ingly, it is also a translation surface! 
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Example 3: Helical surfaces. When the generating line g is not only rotated 
about an axis a (the z-axis) but also translated proportionally along a, the 
generated surface is a helical surface (Figure 5): 


Lo(u) cosv — yo(u) sinv 
E(u, v) = | xro(u) sinv + yo(u) cosv (c...constant parameter). (12) 
zo(u) +cvu 





FIGURE 5. Ruled and tubular helical surfaces. 
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Example 4: Rotoidal surfaces. A possible generalization of the helical mo- 
tion is the “rotoidal motion”: we replace the proportional translation along 
the axis a by a proportional rotation about an axis b (ratio c). The axis b is 
skew and perpendicular to a and rotates around a (Figure 6).1 The gener- 
ated rotoidal surfaces have the equation 


(xo(u) — 2(u) coscv) cosu — yo(u) sinv 
E(u, v) = | (xo(u) — 20(u) if sin v + yo(u) cos v (13) 
zo(u) sin cu 





FIGURE 6. Ruled and tubular rotoidal surfaces. 


‘The motion converges to the helical motion when b converges to the infinite 
line ((GLAE81)). 
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Example 5: Spiral surfaces. At last an example of a family of surfaces where 
the generating line g is not only moved in space but scaled as well. We rotate 
g about an axis (the z-axis), and we apply a proportional scaling to g with a 
fixed point on the axis (e.g., the origin) as its center. The generated surfaces 
are then spiral surfaces (Figure 7, Figure 8 and Figure 20): 


(xo(u) cosu — yo(w) sin v) e 
z(u,v) = | (2o0(u) sinv ; on cos v) e® (c...constant). (14) 
Zo(u) ec” 


) 


out Iie is 
Ee 
yh Le 








FIGURE 7. Ruled and tubular spiral surfaces. 
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FIGURE 8. Minimal spiral surfaces are bent into one another without altering the 
metric of the surfaces (vanishing main curvature!) ([(WUND54)). Similar bendings exist 
for any type of minimal surfaces, e.g., for the transformation of a helicoid into a catenoid 


([GLAE88 /2]). 


8.3 Surfaces Given by Implicit Equations 


The set of points P(x, y, z) that fulfills a condition F(z, y, z) = 0 is also a 
surface ®. The function F(z, y, z) is called the “implicit equation” of ®. If F is 
an algebraic function 


F(a, y, z)= > azne'yz" =0 (i,j,k >0, aij, = constant) (15) 
ttj+k<n 
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in 7, y and z, the surface is algebraic as well. The highest exponent n in Equa- 
tion 15 is called the “degree” of an algebraic surface ®. It can be interpreted as 
the highest possible number of intersection points of ® with a straight line. For 
example, the surfaces given by the linear implicit equation 


F(a, y, Z) = a100% + aor0y + A0012 + Go00 = 0 (16) 


are all identical with planes in space. 


The general quadratic equation 


F(z,y,z) = 4200 x” + ao20 y” + ago2 27 + 
+4110 LY + A011 YZ + A101 2X + 
+4100 © + Aoi0 Y + Goo1 Z + Ao00 = 9 (17) 


describes the surfaces of degree 2. Among these “quadrics”, we have the spheres 
or, more generally, the ellipsoids, the paraboloids and the hyperboloids. Special 
cases are the elliptic (parabolic, hyperbolic) cylinders and the elliptic cones. 


In simple cases, it will be possible to find the implicit equation of a surface when 
its parametrized equation is given and vice versa. 





FIGURE 9. Parametrization of a torus. 


A torus (Figure 9), for example, can be described by the parametrization 


(a — bcosv) cosu, 
£(u,v) = | (a — bcosv)sinu, (u € [0,27], v € (0, 27]). (18) 
bsin v 
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The parameters u, v can be eliminated, which leads to 


F(z, y, z) = (a—- V2? +y2)? + 2? —b? =0 (19) 
or 
F(a, y, 2) = (27 + y? +2* +a? — b*)? — 4a?(2? + y*) =0. (20) 


Thus, a torus turns out to be an algebraic surface of degree 4. 


An interesting surface can be generated from a torus by “inverting” it with 
respect to a sphere (Figure 10). Let C(xzo, 0, 0) be the center of the sphere and 
o be its radius. Then the inversion is given by 


0” 


Without proof, the surface is also of degree 4, and it is called “Dupin’s cyclid” 
([WUND66}). 





FIGURE 10. The inverse surface of a torus with respect to a sphere is called “Dupin’s 
cyclid.” 


Special Curves on Mathematical Surfaces 


A line of intersection of two surfaces can only be parametrized in special cases. 
The same is true for the contour lines of surfaces or “integral curves” on surfaces 
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(Section 8.5). Furthermore, it often takes a lot of CPU time to calculate enough 
points on the line for a smooth image polygon. 


Fortunately, many important classes of curves on surfaces ® (Z(u,v)) can be 
characterized by a condition f(u, v) = 0. 


We will now develop a subroutine zero_manifold_of_f_uv(), which can be used 
to trace curves that are characterized by an equation f(u, v) = 0. The result will 
be a contiguous (sorted) set of parameter pairs (u, v). Considering the impor- 
tance of such a routine for geometrists, it is not surprising that a number of dif- 
ferent solutions of the problem have been described (see, for example, [SEYB77], 
[PAUK86], [GLAE86]). The routine we will develop does the job comparatively 
fast, provided that the result does not have to be extremely accurate (there is no 
restriction to accuracy, however, if we do not mind longer periods of calculation 
time). 


The idea is the following: if we interpret w = f(u, v) as the third coordinate 
of a Cartesian (u, v, w) system, the solution of f(u, v) = 0 consists of all the 
intersection points of the graph: w = f(u, v) with the plane G: w =O. The 
zero manifold of f(u, v) can, thus, be interpreted as the planar line of intersection 
s =I, which may consist of several branches. 


Equation 22 defines a one-to-one correlation between the surface and the base 
rectangle in the (u, v)-plane @. Therefore, we have a one-to-one correlation be- 
tween those lines of intersection of function graphs and curves that fulfill a con- 
dition f(u, v) = 0 on a surface z(u,v). Every point S(u,, v,) on the line of 
intersection s then corresponds to a point P(x, y, z) on the desired space curve 
on the surface: c = r(Uz, Us), Y = y(Us, Us), 2 = 2(Us, Us). 


It is easy to find a large set of intersection points of the graph. The problem, how- 
ever, is to connect these points to polygons (this enables us to draw line segments 
instead of little dots on the screen). The key to the solution lies in the triangu- 
lation of the graph T°. 


We calculate a comparatively small number of points on [ that are above a grid 
on the horizontal base rectangle (u € [u1, ue], v € [vj,v2]) and triangulate this 
approximating polyhedron. In order to get the best triangulation possible, we 
use “average normals” in each point of the polyhedron. 


Now we intersect each triangle with the base plane {. For all the triangles that 
have a line of intersection, we store the two pointers to the vertices of the re- 
spective segment of the line of intersection. This enables us to connect the line 
segments to polygons. Most of the intersection points will be reached twice, be- 
cause, in general, two neighboring triangles have one side in common. Thus, we 
start the following algorithm: 


We identify a first branch of s with an arbitrary line segment {ao, a1}. If there is 
a line segment {a1, a2} (or {@2, a:}) among the residual segments, we enlarge the 
branch to {ao, a1, a2}. This procedure is repeated until no further line segments 
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can be added. The branch has now grown to {do, @1,..., @m—1; @m}. If ag = am, 
the branch is a closed line, otherwise we try to continue it from its other end. 
Without altering the branch, we swap its points to {am, @m-1,..., @1, ao}. If 
there is a line segment {@9, Gm+i} (or {@m41, @o}) among the residual segments 
({ao, a1} has already been concatenated), we add it to the branch and so forth 
(= {a0, Gm41,-.-, @s}). The current (k-th ) branch then consists of s+ 1 points. 


We trace new branches until there are no residual segments left. 


A C version (concat_to_polygons()) of the algorithm is listed in Section 6.1. Since 
it works almost exclusively with pointer arithmetic, we also list a pseudo-code 
for better understanding: 


residual segments rs = all line segments 
nm := number of residual segments 


k := 0 

repeat 
{branch|k] 01, branch[k][1]} := rs(0] 
rs|0] = rs[n] 
s:= 1 


closed := FALSE 
first.chain := TRUE 
repeat 
repeat 
b := branch|k]|[s] 
if exists rs[i] with {b, succ} V {succ, b} 


S$ := s+l1l 
branch|k][s] := succ 
n:= n-1 

rs{i] := rs[n] 


if succ = branch|k](0] 
closed := TRUE 
until closed V n = 0 V no succ found 
size[k] := s+1 
if not closed A first_chain 
fori := 0 to s/2 

swap(branchik [i], branch|k][s — ¢]) 

first.chain := FALS 
until closed V -— First chain Vn=0 


k := k+1 
until n = 0 
no_of branches := k 


In this manner, the line of solution can be found very quickly. The result, how- 
ever, is not as satisfactory as one might expect it to be. Because we replace the 
graph by a polyhedron, the line of intersection will hardly be very smooth, unless 
we drastically increase the number of the faces of the polyhedron. 
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FIGURE 11. The parameter lines on the graph [ are approximated piecewise by 
means of cubic parabolas. Such a parabola is determined by two “line elements.” 


To make the curve s smooth, we replace the sides of the intersecting triangles by 
planar cubic parabolas (Figure 1la). The plane w on which such a parabola lies 
is normal to the base plane (. The parabola itself is determined by the two end 
points P,; and P, and by the “average” normals n; and nz in P, and P>. The 
tangent t; of the parabola in P; is normal both to n; and to the normal p of w. 


Figure 11b illustrates the situation in ~. We introduce a local two-dimensional 
coordinate system (t, w). The parabola will have the equation 


w=at?+bt?+ct+d. (22) 


The two given points may have the coordinates P,(0, w;) and P2(1, we). Thus, 
we have (1)...w,; = d and (2)...w. = a+6+c+d. The slope of a general 
tangent of the parabola is given by the first derivation 


w= - = 3at? + 2bt +c. | (23) 
The slopes of the tangents ¢; and tz may be k, and kp. Thus, we have (3) ...k, =c 
and (4)...k2 = 3a + 2b+c. The equations (1) ...(4) lead to the coefficients of 
the parabola: 


a=ky + ke —2(we — wi), b= 3(we — wi) — 2k1 — koa, c= ki, d= wy. (24) 


Now we have to intersect the parabola with w = 0. This can be done quickly 
by NEWTON’s iteration ([FOLE90]). The solution point may have the local 
coordinates S(A,0). In the (u, v)—coordinates, the point S is then described by 


Su = Diy tA(Poy — Plu), Sv = Ply t+ A(P2y — Ply): 
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Let us now gradually develop the necessary code for the important function 
zero-manifold_of -f uv(): 


/* We need a pointer to a function f(z). */ 


Global Init_fptr(f-2, cubic_parabola); (— Proto.h) 
/* This is the initializing function. + / 


float Coeff [4]; 
/* Global in the current module. */ 


float cubic_parabola(z) (— Proto.h) 
float z; 


{ /« begin cubic_parabola() */ 
return ((Coeff[0] «x + Coeff[1]) *2+ Coeff [2]) *x + Coeff (3); 
}  /* end cubic_parabola() */ 


/* The next function tries to find the zero of f(x). */ 


= FT 
float zero_of -f _x-with_newton(x, eps, ok) (— Proto.h) 
float x, eps; 
Bool * ok; 


{ /« begin zero_of _f xc_with_newton() */ 
float x0, Y; dr = le — 4; 


short i= 0; 
do { 
in = F; 
= f_x(x0); 


= £0 -y /((f-«(z0 + dz) —y) /dz); 
} while (fabs(a — 20) > eps && ++i < 10); 
*xok = (i< 10? TRUE : FALSE); 
return 7; 
} /* end zero_of _f_xc_with_newton() */ 


/* The iteration by NEWTON works fast, but it does not converge in any 
case. Thus, we need another function for the determination of the zero of a 
function. */ 
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| 
float zero_of _f x-with_bin_search(xl1, dz, yl, eps) (— Proto.h) 
float r1, dz, y1, eps; 


{ /* begin zeroof _f_xc_with_bin_search() */ 
float x0, y0, dz; 


if (dx < eps)return 21; 


dz /= 2; 
x0 = zl + dz; 
yO = f-2(z0); 


if (fabs(y0) < EPS) return 20; 
else if (yl *y0 < 0) 
return zero_of_f_x_with_bin_search(x1, dz, y1, eps); 
else 
return zero_of_f_x_with_bin_search(x0, dz, y0, eps); 
} /* end zero_of _f _x_-with_bin_search() */ 


/* Now we can find the zero of a cubic parabola. */ 


| 
float zero_of _cubicpar(a, b, c, d, start_z) (— Proto.h) 
float a, b, c, d, start_z; 


{ /x* begin zero_of -cubic_par() */ 
float 7; 
Bool ok; 


Coeff [0] = a; Coeff[1] = 6; Coeff|2] = c; Coeff[3] = d; 

f-x = cubic_parabola; 

x = zero.of_f_x_with_newton(start_c, le — 3, &ok); 

if (ok) return 7; 

else return zero_of_f_x_with_bin_search(0.0, 1.0, d, le — 3); 
}  /* end zero_of -cubic_par() */ 


/* The following function checks whether two vectors are (more or less) 
identical. +/ 


Bool identical(a, b) (— Proto.h) 
Vector a, 5; 
{  /x begin identical() */ 
#define SMALL le — 4 
if (fabs(a[X]—b[X]) > SMALL 
|| fabs(al[Y]—b[Y]) > SMALL 
|| fabs(a|Z] — b[Z]) > SMALL) return FALSE; 
else return TRUE; 
#undef SMALL 
}  /* end identical() */ 
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FIGURE 12. How to determine the “average normals” of a surface. 


/* The next function takes a given grid of points on any surface and determines 
possible normals of the surface in these grid points (Figure 12). */ 


a aa i is aaa 
void average_normals(normal, grid, imaz, jmaz) (— Proto.h) 

Vector «normal; /* Average normals in grid points (2d). */ 

Vector x«grid; /* Grid of basepoints (2-dimensional). +/ 

short imaz, jmaz; 

/* Size of grid: 0 <i < imaz,0<j < jmaz. */ 

{ /x begin average_normals() */ 

Vector n, dif f[4]; 

short i, 7, k, k1; 

register Vector * p, xaverage-normal; 

Vector * (4); 

Bool closed|2); 


closed[0| = identical(grid[0|[0], grid[0|[jmax — 1)); 
closed[1] = identical(grid{imaz —1][0], grid{0}[0}); 
for (i= 0; i1< imaz; i++) 
for (j = 0; 7 < jmaz; j++) { 
p = v0] = vf[l] = vf[2] = [3] = (Vector +) grid{il[y]; 
if (i> 0) v[0] = (Vector *) grid[i — 1][J]; 
else if (closed[1]) v[0] = (Vector *) grid[imaz — 2]|j]; 
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if (j > 0) v[1] = (Vector «) grid{i][j — 1]; 

else if (closed(0]) v{[1] (Vector *) grid[i][jmaz — 2]; 
if (¢+1 < imaz) v{2] (Vector *) grid{i + 1][j]; 
else if (closed(1]) v[2] (Vector «) grid[1][j]; 

if (gj +1 < jmaz) v{3] (Vector *) grid[i][j + 1]; 
else if (closed[0]) v{[3] (Vector «) grid/i][1]; 


for (k = 0; k < 4; k++) 


if (u[k] != p) 
Subt_vec(dif f[k], *p, *v[k]); 
average-normal = (Vector *) normal(i](j]; 


Zero_vec(*average_normal); 
for (k = 0, kl = 1; k < 4; k++, kl = (k14+1)% 4) { 
if (v[{k]!= p && v{ki] != p) { 
Cross_product(n, dif f[k1], dif f[k]); 
normalize_vec(n); 
Add_vec(*average_normal, *average_-normal, n); 
} /* end if (v[k]) */ 
} /* end for (k) */ 
normalize_vec(*average-normal); 


} /* end for (7) */ 
} /* end average_normals() */ 


/* The following function checks whether the k-th side of the triangle tri inter- 
sects the base plane w = 0. The side is interpolated by a cubic parabola and 
the point of intersection is calculated by means of NEWTON’s iteration. */ 


typedef Vector Triangle [3]; (— Types .h) 
| 
Bool cut_line(sec, tri, k, grid, normal) (— Proto.h) 

Vector sec; 

Triangle tri; 

short k; 


Vector *«grid, «normal; 


{ /x* begin cutline() */ 
register Vector «pl = tri(k], *p2 = tri[(k + 1)%3j); 
register float f; 
Vector * temp; 
static Vector n = { 0, 0, 0}; 
Vector *nl, *n2, tgl1, tg2; 
float y1, y2; 
float k1, k2; 
Vector2 dif f; 
float scale; 
float h1, h2; 
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} 


if (Sign((*p1)[Z]) == Stgn((*p2)[Z])) return FALSE, 


if ((xpl)[Z] > 0) 
Swap(pl, p2); 

/* Normal of projecting plane through side of triangle. */ 

Subt_vec2(dif f, *p1, *p2); 

Normal_vec2(n, dif f); 

/* Idealized a in pl and p2. «/ 

nl = normal|0 pl — grid\0}); 

n2 = normal)0 p2 — grid\0 


/* Tangent sectors in pl and p2. « / 

eileen iy xn1, n); 

Cross_product(tg2, *n2, n); 

/* The tangent vector must have the same direction. */ 
if ot reams. di f i} < ; atin bs rs 











if (Dot_product2(tg2, diff) < 0) Turn_vec(tg2, tg2); 
yl = (*1)[2Z); y2 = = (*p2)[Z]; 

if (yl= y2) t = 0.5; 

else { 


scale = (ar Len ff); 


k1 = tgl1[Z] /(Length2(tg1) /scale); 
k2 = igre A (Length2| tg2 /seale) 
hl = — _ 


Pe cere of cubic par( Me * hi — h2, h2 + 3 * Al, 
kl, yl, yl / (yl — y2)); 


sec[X] = ee + tx dif f[X]; 
sec|Y| = (*pl)[Y] + t* dif f[Y]; 
sec|Z| = 0; 





return TRUE. 
/* end cutline() */ 


/* The next function checks whether a point has already been stored in a pool 


of size n. */ 


| | 
Vector * ptr.to_section(p, pool, n) (— Proto.h) 
Vector p; 


} 


register Vector * pool; 
register short n; 
/* begin ptr_to_section() */ 
while (n—- > 0 
if (zdentical(*pool, p)) 
return pool; 
pool++; 


return NULL; 
/* end ptrto_section() */ 
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/* The following function “measures” how much the normal vector of a triangle 
differs from the desired normal vectors in its vertices: it returns the sum of 
all deviation angles. +/ 


| 
float deviation(tri, grid, normal, il, j1, i2, 72, 73, 73) (— Proto.h) 
Triangle tri; 


Vector «grid, normal; 
short 71, j1, 12, 72, 73, 73; 


{ /« begin deviation() */ 
Vector face_normal; 


tri[0| = (Vector *) grid[i1]|[j1); 

tri[1] = (Vector *) grid[i2][72]; 

tri[2] = (Vector *) grid[i3][j3]; 

normal_vector(face_normal, tri); 

return acos(fabs(Dot_product(facenormal, normal(i1]|j1]))) + 
acos( fabs(Dot_product(face-normal, normal|{i2|[j2]))) + 
acos( fabs( Dot_product( face-normal, normal|i3|[j3]))); 

}  /* end deviation() */ 


#define MAX_SECTIONS 2000 


/* The following function determines the optimized triangulation plus the opti- 
mized normals of a surface. Space for the variables triangles and normal is 
allocated in the routine and can be freed outside the function. */ 


void triangulate_sur face(total_tri, triangles, 
normal, surf, imaz, jmaz) (— Proto.h) 

short +total_tri; /* Number of triangles. */ 
Triangle +triangles; /* The optimized triangulation. */ 
Vector ***normal; /* Pointer to all normals. */ 
Vector +surf; /* Grid of points in the surface. */ 
short imaz, jmaz; 

/* Size of grid on the surface: 0 <i <imaz, 0<j < jmaz */ 


{ /x begin triangulate_sur face() */ 
short 1, j, k; 
static Triangle * tri_pool; 
register Triangle * tri; 
Triangle alt|2}; 
static Vector «nrm; 
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Alloc_2d_array(Vector, nrm, imax, jmaz); 
average_normals(nrm, surf, imax, jmazx); 
*normal = nrm; 
/* Triangulate graph. */ 
*total.tri = 2 *(imaz —1) *(jmazx — 1); 
«triangles = tri = Alloc_array(Triangle , tri_pool, *total_tri, "tri-pool"); 
for (i= 0;1< imax —1; i++) 
for (j = 0; j < jmaz —1; j++, tri+= 2) 
/* Create two pairs of test triangles and compare their 
deviations. Choose the ‘better’ pair of triangles. */ 
if (deviation(tri[0|, surf, nrm, i, j,i +1,9,¢+1,7+1)+ 
deviation(tri[1], surf, nrm,i+1, 7+1, i,7+1,%, 3) > 
deviation(alt(0|, surf, nrm, i, 7 +1, 4, j,i +1, j)+ 
deviation(alt[1], surf, nrm,i+1, j,i+1,j74+1,i,74+1)){ 
for (kK = 0; k < 3; k++) 
tri[O|[k] = alt[0|[k]; 
for (k = 0; k < 3; k++) 
tri(1][k] = alt[1][k]; 


} /* end triangulate_sur face() */ 


/* This is the function that determines the line of intersection of the function 
graph w = f(u, v). This line consists of a number of branches. As a side ef- 
fect, this function determines the optimized triangulation plus the optimized 
normals of the surface. */ 


void zero_manifold_of _f -uv(section, triangles, nrm, 
total_branches, branch-size, branch, 
grid, imaz, jmaz) (— Proto.h) 
Vector **#nrm; /* Pointer to all normals. */ 
Vector +*section; /* Address of the array of solution points. +/ 
Triangle «triangles; /* The optimized triangulation. «/ 
short + total_branches; /* How many solution curves. +/ 
short + branch_size; /* Size of each solution curve. +/ 
Vector +**branch; /* Array of array of pointers into section. +/ 
Vector x«grid; /* Grid of basepoints (2-dimensional) */ 
short imaz, jmaz; 
/* Size of grid on the surface: 0 <i < imaz, 0< j < jmaz */ 
{ /* begin zero_mani fold_of_f_uv() */ 
short j, k, n, total_tri; 
static Vector * space; 
static Triangle * tri_pool; 
short found; 
Vector + ptr; 
Edge *line_pool, line; 
short total.sections; /* How many section points. */ 
static Vector *normal; 
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triangulate_sur face(&total_tri, &tri_pool, &normal, grid, imax, jmaz); 
* triangles = tri.pool; *nrm = normal; 


/* Allocate section points +/ 


* section = Alloc_array(Vector, space, MAX_SECTIONS, "space"); 
line = Allocarray(Edge, line_pool, MAX_SECTIONS/2, "1ine-pool"); 


n = total_sections = 0; 
for (j = 0; 7 < totaltri; j++) { 
found = Q; 


for (k = 0; k < 3; k++) { 
if (cutline(*space, tri_pooll|j], k, grid, normal)) { 
found+-+; 
ptr = ptr_to_section(*space, section, total_sections); 
if (!ptr) { 
ptr = space+-+; 
if (++total_sections > MAX_SECTIONS) 
safe_exit("too many sections"); 
} /* end if (!prt) */ 
if (found == 1) 
line—>vl1 = ptr; 
else { 
line—>v2 = ptr; 
line++; 
break; 


} 
} /* end if cut_line «/ 
} /* end for k */ 
}  /* end for j */ 
n = line —line_pool; 
if (n == 0) 
* total_branches = 0; 
else { 
Alloc_ptr.array(Vector, branch|0|, 2 *n, "branch[0]"); 
concat_to_polygons(total_branches, branch-_size, branch, 
n, line_pool, FALSE); 


Free_mem(line.pool, "1line-pool"); 
}  /* end zero_manifold_of _f -uv() */ 


After these general considerations, we will now present three examples in order 
to give you an idea of what the function f(u, v) may look like: 
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FIGURE 13. How to approximate the normal of a mathematical surface. 


Example 1: Contour Lines. A point on a surface is considered to be a con- 


tour point if the corresponding tangent plane coincides with the projection 
center, that is to say, if the projection ray is orthogonal to the normal vector 
of the surface (Figure 13). Let us approximate the tangent vectors Z,, Zy 
of the parameter lines: 


Ox = —_ = 

os = ty = (Lu, Yu, Zu) = Z(u +E, v) — (u —&; v), (25) 
OL = ~ = 

Ov = Ly = (25; You» Zy) = (u, U+ €) — t(u, v— E), € small. 


Then the normal vector nm can be approximated by the vector product of 
these difference vectors: 


n=, 2. (26) 


The condition for the existence of a contour point is that the dot product 
of the normal vector and the projection ray vanishes 


f(u, v) = 7i(u, v).(Z(u, v) — €) = 0, (27) 


where Cc is the position vector to the projection center. 


A function contour _condition(u, v) may have the following code. 
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FIGURE 14. Contour lines on mathematical surfaces. 
Global Init_fptr(xyz, xyz-_torus); 
float contour_condition(u, v) 


float u, v; 


{ /x begin contour_condition() */ 


Vector p, n, proj_ray, pul, pu2, pul, pu2, tu, tv; 


float eps = le — 2; 


ryz(p, u, v); 

ryz(pul, U— eps, v); 
ryz(pu2, u+ eps, v); 
zyz(pul, u, vu — eps); 
ryz(pv2, u, u+ eps); 


Subt_vec(tu, pul, pu2); Subt_vec(tv, pul, pv2); 


Cross_product(n, tu, tv); 

normalize_vec(n); 

Subt_vec(proj-ray, p, Eye); 

normalize_vec(proj-ray); 

return Dot_product(proj-ray, 1); 
} /* end contour_condition() */ 


(— Proto.h) 


(— Proto.h) 
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/* This is the initializing function for cyz(). */ 


void ryz_torus(p, u, v) (— Proto.h) 


} 


Vector p; 

float u, v; 

/*x begin zyz_torus() */ 

float cu, su, 7; 

floata = 3, b= 2; 

cu = cos(u); su = sin(u); 

r= a+ bx cos(v); 

p[X] = r* cu; p[Y|] = rx su; p[Z] = b* sin(v); 
/x end zyz_torus() */ 


bo 


Example 2: Isophotes. Isophotes are those curves on surfaces along which 


parallel light rays enclose a constant angle with the surface (Figure 15). For 
this reason, they are also called lines of equal illumination.? Consequently, 
the angle between the normal vector of the surface and the corresponding 
light ray is invariable for each point on such a line. This means that from 
the mathematical point of view, the dot product. of the normalized normal 
vector fig and the normalized light ray vector Ip equals the cosine of the 
given constant angle of incidence 8 (Equation 14). Thus, the condition for 


f(u, v) is 
f(u, v) = tlo(u, v) .1o(u, v) — cos 8 = 0. (28) 


Example 3: Lines of Intersection with Other Surfaces. We now want to 


intersect the surface ® with another surface W (e.g., with a plane, a sphere or 
a cylinder; Figure 16). In most cases, especially with algebraic intersecting 
surfaces, the implicit equation G(z, y, z) of Y can be given. The coordinates 
of the points on the line of intersection have to fulfill this condition as well, 
and thus, we get 


f(u, v) =G(a(u, v), y(u, v), z(u, v)) =0. (29) 


If the implicit equation of the surface cannot be calculated, we may try 
to parametrize the intersecting surface W and find an implicit equation 
F(a, y, z) of the surface ©. 


Note that this method is not appropriate for the calculation of the self- 
intersections of a surface. In this case, we would get f(u, v) = F(z, y, z) = 
0, i.e., the graph I’ would be identical to the base plane @ so that a line 


“If the light rays were not parallel, we would have to take the distance from 


the light source into account as well. 
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FIGURE 15. Isophotes on mathematical surfaces. 
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8.9 


of intersection could not be detected! To calculate the self-intersections, we 
have to check for each face of the polygonized surface whether it intersects 
other faces or not. The intersection segments can be concatenated in the 
above-mentioned manner. 





FIGURE 16. The intersection of a hyperboloid and a torus. The surfaces are given 
by their parametrized equations Zpyp(u, v) and Ztor(u, v). Furthermore, we know the 
implicit equation Gior(z, y, z) of the torus. The line of intersection corresponds to the 
zero manifold of the graph z = Gtor(Xayp, Yryp, Zhyp) (image on the left). 


A More Sophisticated Illumination Model 


In Section 4.5, we developed a simple shading model that is suitable for “ordi- 
nary” polyhedra like cubes. We also mentioned that it is not perfectly suitable for 
polyhedra that are approximations to smooth reflecting surfaces. Therefore, we 
want to extend our shading model according to the ideas of L. Phong [BUIT75]. 


It is a fact that shiny surfaces have highlighted spots. These spots do not only 
depend on the angle of incidence of the light rays — in each point of a shiny 
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surface, the incoming light ray will be reflected according to the law of reflection 
(Figure 17): the incoming light ray, the reflected light ray and the normal of 
the surface lie on the same plane and the angle of incidence equals the angle of 
reflection. If the reflected light ray hits the eye point, the point on the surface is 
highlighted. Points that are close to the highlighted spot can also be considered 
to be highlighted, provided that the “perfect reflection ray” does not pass too 
far from the eye point. This is due to the consistency of the surface, which will 
never be perfectly smooth so that every spot will send out a bundle of non- 
parallel reflected light rays. 





FIGURE 17. The law of reflection. 


If n is the normalized normal vector in the point P of the surface and i,, the 


normalized direction vector of the light ray Pl through the n-th light source, 
the reflected ray has the (normalized) direction 


F=h+(h—I,) =2h-1, with h = (#i,)i. (30) 
We now modify Equation (2) by means of the formula 
s = reduced_palette [k; cosa + kz w(a) cos™{). (31) 


In this formula, 6 is the angle enclosed by the reflected light ray and by the 
projection ray PC’; w(a) is a function that depends on the angle of incidence a 
of the light ray and on the material the surface consists of; m is a constant that 
is the higher, the more reflecting the surface is and k, and kg are also factors 
that depend on the material of the surface. Good values for reflecting surfaces 
are 


22<m< 2", 0.2 < ky <0.5, kp = logam = logm/log2. (32) 
If p is the normalized direction vector of the projection ray, we have 


cos 3 = pr. (33) 
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FIGURE 18. Four different shadings of one and the same surface: plastic, metallic, 
wooden coatings, normal shading. 


The function w(a@) can only be described by means of measured data 
([PURG85]). The graph is described only by a few data and is then interpo- 
lated by cubic splines (Chapter [9]). Sometimes w(q) is simply set to a constant 
((FOLE90)}). 


Equation (31) does not take the color of the light source into account (it assumes 
that the light source is white).° If the shade value s is larger than the palette 
size, we take the largest possible value instead. 


Figure 18 shows a surface of revolution where the material-dependent constants 
are varied. 


*Colored light sources produce highlighted spots of the same color on the 
surface. Since we only deal with lookup-tables for RGB colors, we cannot produce 
new RGB colors during the rendering. The only thing we can do is to create 
palettes of mixed colors. For example, if we deal with a gray surface and if the 
light source is red, we can create a small palette consisting of some light red-gray 
shades that replace the brighter shades of the red palette. 
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Shadow Buffering for Shadows 


In Chapter 7, we talked about a very common and general working algorithm 
(depth buffering or z-buffering). In Chapter 6, we saw that, from the geometrical 
point of view, there is no difference between the light systems and the screen 
systems. For this reason, we can do the following: 





FIGURE 19. Shadow buffering generally works and the algorithm is comparatively 
fast, but it requires large amounts of RAM to create images of good quality. 


We transform the n-th light coordinates of all the vertices of the scene linearly 
into a box M, x N, x 65000. Before we do the depth buffering of our polygons, 
we buffer the scene completely in all the light systems. 


If we then want to plot a visible pixel, we first transform the corresponding “space 
point” (actually it is a tiny box) to all the light systems and check whether the 
depth value w* of the point corresponds approximately to the buffered value in 
the system. If w* is smaller than the buffered value, the point is shadowed in 
the corresponding light system. Finally, the pixel is given a shade that depends 
on how often it has been shadowed, similar to the calculation of the shades for 
shadow polygons. 


An estimation of memory requirements shows that again we will need 
0.5 MB RAM for each light source, even if we use a comparatively small grid 
size of 500 x 500 in the light systems. It is no longer possible to split the grid into 
horizontal zones as we did in the ordinary depth buffering because, in general, 
the polygons, the n-th light coordinates of which are covered by the grid strip 
in the n-th light system, will not be covered by a strip in another system. 


If we run out of memory, a compromise is the only solution. We transform the 
depth values to the interval [0,255]. This interval can be covered by the type 
Ubyte which needs only one byte of storage space. Such a restriction also means 
that a narrow grid does not make sense any more, so that we reduce our grid 
size to about 250 x 250 in the n-th system. 
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Now the whole buffer in the n-th light system needs less than 64 Kbytes.* The 
price to be paid for this restriction is a loss of accuracy when we plot shadows 
(Figure 19). 





FIGURE 20. These images of a nautilus and a snail were created by means of shadow 
buffering. In nature, you can find a lot of spiral surfaces (Section 8.2, Example 5), 
because they are a result of continuous growth. 


“In addition to that, blocks of a maximum of 64 Kbytes can be accessed much 
faster by some operating systems. 


9.1 


9 


Spline Curves and Spline Surfaces 


Interpolating Curves and Surfaces 


In the previous chapter, we used cubic parabolas (Equation 22) to interpolate 
the line of intersection P,P: of the graphT with a vertical plane ~. Analogously, 
a patch Y on I’, which is roughly approximated by two triangles, can be replaced 
by a cubic graph that consists of all the cubic parabolas we get when we vary 
the plane 7. Such a graph is called an “interpolating surface.” 


If we concatenate several cubic parabola segments in the same plane wy, the 
new line is called a “spline curve.” The breakpoints are also called “knots.” 
The arch between two knots is a “span.” In each knot, the two neighboring 
spans touch each other because they have the same tangent. This is called C 1 
continuity [FOLE90]. However, the local characteristics of each segment may 
be quite different, and the concatenated curve does not necessarily look very 
smooth. 


All the parabolas described by Equation (22) have one thing in common: they 
never have vertical tangents (w = 0 in Equation (23) occurs only for t = -too). 
Each parabola has its infinite point in the direction of the w-axis. This is no 
restriction as long as we only want to interpolate a function graph (which by 
definition must not have vertical tangents). For general surfaces, however, we 
have to generalize the cubic span p by means of a parametrized equation: 


#=(2,y,z)=a+b+ét+d. (1) 
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Note that, in general, the infinite point of the parabola (t = too) will not be 
the infinite point of an axis. Furthermore, the curve is really three-dimensional 
and not planar any more. 


Let (P,, t1) and (Pe, te) be two “line elements” of the parabola p. They may 
fulfill Equation (1) for t= 0 and t = 1. By means of the first derivation 


dx dx dy dz 


ww (O_o 5) — 2772 LOREAL 
= (Ge ge q) = (bw 2) = 3a? +2 +4 (2) 


r= 


we get the “coefficient vectors” almost in the same manner as in Section (8.2): 


@ = t+t,-2(r-n), 

b = 3(f2—p1)-2h-b, 

é= hh, 

d = fi. (3) 


Any point on p between P; and P2 can be calculated by evaluating Equation (2) 
with a t-value between 0 and 1. 


Interpolating Splines 


Now we have two line elements and are able to calculate an arbitrary number of 
points on the cubic span p. For many applications, however, we also have to solve 
the following problem: given a polygon QoQ1,...,Qn, we try to find a smooth 
curve that interpolates the polygon that is given by the n+ 1 control points. In 
principle, we can “make up” n+1 arbitrary tangent vectors t; in Q;. Then the n 
cubic spans between Q; and Qj; are determined by two line elements each, and 
we have a set of parabola segments without any sharp bends (C* continuity). It 
turns out, however, that the visual impression of this interpolating spline curve 
is heavily dependent on the tangent vectors we choose. For many purposes, it 
is a good idea to let the tangent vector ¢; in Q; be dependent on two points 
before Q; and two points after Q; (Figure 1). 


For the determination of the tangent vectors, several methods have been devel- 
oped ([PURG85]). Good results can be achieved with the approach proposed by 
Akima. Since Q_1, Q-2, Qn41 and Qn+2 are not given, we say 


Gd-1 = g2+3(g-4G) 
d-2 = G1 +3(¢-1-40) 
Qn+1 = Qn—2 +3 (Gn _— Gn—1) 


On+2 — Gn—1 +3 (Qn+1 — Gn). (4) 


Now we define 


ts[7] = Ar [7] Q:Qi-1[9] + zl] Q2Qi+i[3] (j = 0,1,2) (5) 
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FIGURE 1. Spline interpolation (Akima). 


and 


dil] = tr nis #h+h>0 |, -|9,Q,25]|, lb=QOncl]|). (6) 


otherwise. 


A set of points interpolated in this way will form an interpolating spline curve 
without any unwanted oscillations, which tend to occur especially at the end 
points of the curve. (This would be the case if we tried to force an algebraic 
curve of degree n to go through our n+ 1 control points.) 


Here is the C code for the calculation of an arbitrary set of points on an in- 
terpolating spline curve that is given by n + 1 control vertices Q;. For each 
span Q;Q;+1, we calculate s; points so that we have m = s9 +... + 8,_1 points 
on the spline curve at our disposal. 

#-define AKIMA 0 (— Macros.h) 


void akima_spline_curve(m, vertices, n, ctrl_point, span_size) 
(— Proto.h) 
short *m; /* Number of points on the curve. +/ 
Vector vertices| ]; /* Array of points on the curve. «/ 
short n; /*« N rons of control points. */ 
Vector crt point ; * Array of control points. */ 
short span_size| Number of points on each span. */ 


{ /x* begin presage */ 
Vector coe f f [4]; 
register float +a, *b, *c, *d; 
Vector * tangent; / * Tangent vectors in the control points. x / 
Vector «tg, *tg1; 
Vector *v = vertices, *hi_v, 
tq = ctrl_point, xhiq = q + n —1, *q]; 
short j; 
float t, delta_t, h; 
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Alloc_array(Vector, tangent, n, "tg"); 
akima_tangents(tangent, n, ctrl_point); 

tg = tangent; 

for (;q < hig; q++, tg++, span_size + +) { 


gi =qt+1; tgl = tg + 1; 
a = &coef f[O|[X]; b= a + 3; c= b+ 3; d = c+ 3; 
for (§ = 0; 7 < 3; j++) { 


h = (*q1)[j] — (+a)b; 


*at+ = («tg)[j] + (+tg1)[9] —2 *h; 
tb++ = 3 *h —2 *(«tg)[7] — (*tg1)[y]; 
tec++ = (x¢g) 3]; 
xd++ = (*q)[i]; 


} /* end for (j) */ 
Copy-vec(*v, *q);  /* Trivial first point. «/ 
t= deltat = 1.0 / * span-size; 
hiv = uvu++ + *span-_size; 
for (; v< hiv; v++, t+= deltat) { 
a = &coef f[0|[X]; b= a + 3; c= b+ 3; d = c+ 39; 
for (j = 0; j < 3; j++, a+, b++, c++, d++) 
(xv)[j] = ((#a *t + *b) xt + #c) «t + +d; 
} /* end for (v) */ 
} /* end for (q) */ 
Copy-_vec(*xv, *q); /* Trivial last point. +/ 
*m = (v—vertices) + 1; 
Free.mem(tangent, "tg"): 
} /* end akima_spline_curve() */ 


| 
void akima_tangents(tangent, n, ctrl_point) (— Proto.h) 
Vector tangent| |; 
short n; 
Vector ctrl_point| |; 


{ /* begin akima_tangents() */ 
short i, imax = 3 *n; 
Vector +diff, *d, *v; 
float lenl, len2, *result; 
register float + d0, *d1l, *d2, *d3; 


Allocarray(Vector, diff, n + 3, "diff"); 
d = diff + 2; 
v = ctrl_point; 
for @= 2;1<= n> i++, d++, v++t) 
Subt_vec(*d, xv, *(v + 1)); 
#define Invent_dif f (dif f vec, a, b) \ 
d = (Vector *) dif f_vec, Add_vec(*d, a, a), Subt_vec(*d, b, *d) 
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Invent_dif f(dif f[1], dif f[2], dif f[3)); 

Invent_dif f(dif f[0], dif f[1], dif f[2]); 

Invent_dif f(diff[n +1], dif f[n], dif f[n—1)); 

Invent_dif f(dif f[n +2], diff[n+1], dif f[n)); 
#undef Invent_dif f() 


dd = &dif f[O\[X]; dl = &dif f[1][X); 
&dif f[2][X]; d3 = &dif f[3][X]; 

result = &tangent(0|[X]; 

for c = 0;i< imaz; i++, dd+4+, dl++, d2++, d3+-+) { 
enl = fabs(+#d3 — +*d2); 

en = = fabs(*d1 — *d0); 

f (lenl + len2 < EPS) 
lenl = len2 = 1; 


xresult+ + = (len1* (+d1) + len2* (*d2)) /(lenl + len2); 


Free.mem(dif f, "aiftf"); 
} /* end akima_tangents() */ 
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Interpolating splines with C1 continuity do not always look very smooth. Curves 
with C? continuity (where even the first derivation of the spline has C? conti- 
nuity) look more natural (Figure 2). Such interpolating spline curves are called 
“cubic splines.” All of the n spans Q;Qi41 (4 = 0,...,n —1) of the spline are 


described by 
Z,(t) = a(t — i)® + 6,(t — i)? + &(t — i) +d; (t € [é,¢ +1). 


The conditions for C? continuity are 


Z(i) = &, i=0,...,n 
Zi(t) = #-1(t4), i=1,...,n 

Z(i) = #;-1(i), i=1,...,n—-1 
Z(i) = 2;-1(i), i=1,...,n—-1. 


For the end points, we let z(0) = x(n) = 0. First this leads to 
d; = Gj ({=0,...,7), 


then to the linear system 


bo 


Bn = (0, 0, 0), 


b-1 +40; + Bina = 3 (dj-1 — 24; + di41) ((=1,...,.n—1), 


(7) 


(10) 
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} 


Alloc_array(Vector, tangent, n, "tg" ); 
akima.tangents(tangent, n, ctrl_point); 


tg = tangent; 


for (;q < hig; q++, tg++, span_size ++) { 
1 


q+ 1; tg1 = tg + 1; 


for (j = 0; 7 < 3; j++) { 
= (*q1)[j] — (*q)[3]; 


ta++ = (xtg)[j] + (*tg1)[y] —2 *h; 
3 +h —2 *(xtg) [i] — (#t91)Li); 


*bO++ 

*C+ + 

xdt++ = (xq)[j]; 
} /* end for (j) */ 


Copy-vec(*v, *q); /* Trivial first point. +/ 


t= deltat = 1.0 /* span_size; 
hiv = v++ + xspan-_size; 


for (; v< hi_v; v++, t+ = delta) { 


a = &coef flO|[X]; b= a + 3; c= 6+ 3; d = c+ 3; 


= &coef f[0|[X]; b= a + 3; c= b+ 3; d = c+ 3; 
for (j = 0; jf < 3: j++, a++4, b+4, c+4+, d++) 


(*v)[j] = ((4a *t + *b) *t + xc) *t + ¥d; 


} /* end for (v) */ 
} /* end for (q) */ 
Copy_vec(*xv, *q);  /* Trivial last point. «/ 
*m = (v— vertices) + 1; 
Free.mem(tangent, "tg"); 
/* end akima_spline_curve() */ 


void akima_tangents(tangent, n, ctrl_point) 


Vector tangent| |; 
short n; 
Vector ctrl_point| |; 


/* begin akima_tangents() */ 

short i, imax = 3 *n; 

Vector «diff, *d, xv; 

float lenl, len2, *result; 

register float *«d0, +dl, *d2, +d3; 


Allocarray(Vector, diff, n + 3, "diff"); 


= diff + 2; 

v= ctrl_point; 

for (i= 2; i <= nj i++, d++, v++4) 
Subt_vec(*d, *v, *(v + 1)); 


#define Invent_dif f (di f f vec, a, b) \ 
d = (Vector *) dif f_vec, Add_vec( +d, a, a), Subt_vec(*d, b, *d) 


(— Proto.h) 
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Invent-dif f(dif f(1], déf f(2], dif f(3]); 

Invent dif f(dif flO], dif f{ll, aif f{2]); 

Invent_dif f(dif f[n +1], diff[n|, dif f[n—1)); 

Inventdif f (dif f[n +2], diffin+1], dif f[n]); 
#undef Invent_dif f () 


d0 = &dif f[O|[X]; dl 
d2 = &dif f[2][X]; d3 
result = &tangent(0|[X]; 
for (i= 0; i< imaz; i++, dd++, d1++4, d2++, d3++) { 

lenl = fabs(*d3 — *d2); 

len2 = fabs(*d1 — dO); 

if (lenl + len2 < EPS) 

lenl = len2 = 1; 
#result ++ = (lenl* (*d1) + len2* (*d2)) /(lenl + len2); 


&di f f[1][X]; 
&di f f[3][X]; 


Free.mem(dif f, "aitt"); 
} /* end akima_tangents() */ 


Interpolating splines with C1 continuity do not always look very smooth. Curves 
with C* continuity (where even the first derivation of the spline has C? conti- 
nuity) look more natural (Figure 2). Such interpolating spline curves are called 
“cubic splines.” All of the n spans Q;Q;41 (z = 0,...,n —1) of the spline are 
described by 


Z,(t) = a,(t — i)? + 6,(t — i)? + &(t — i) +d; (t € [i,i +1). (7) 


The conditions for C? continuity are 


Z(i) = Gi, i=0,...,n 

Z(i) = #,-1(i), i=1,...,n 

Z(i) = Zj-1(i), i=1,....n-1 

Z(i) = #;-1(i), i=1,...,n—1. (8) 


For the end points, we let <(0) = z(n) = 0. First this leads to 


~ 


d; = q; (i=0,...,n), (9) 

then to the linear system 
bo 

b-1+45; + Bist 


bn = (0, 0, 0), 
3(di_1 — 24; + di41) (j=1,...,n—1), (10) 
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Interpolating Surfaces 


Interpolating spline curves can be used for the interpolation of surfaces that are 
given by a grid Q,; of (ni + 1) (no +1) vertices (Figure 3). 





FIGURE 3. Interpolating spline surface (cubic splines). 


We interpolate the n; +1 v-lines (j constant) and the n2+1 u-lines (i constant) by 
means of interpolating splines. Now the v-lines are polygons with mg vertices V;;. 
Vertices V;;, with the same index jp (jo = 0,...,m2—1) determine mz u-lines on 
the surface (including the given ones). In the same way, we can determine new 
v-lines of the surface. The interpolated surface now consists of m1 mz vertices. 
The n 172 patches of the surface are joined together with C1 continuity, if we 
use C! continuous interpolating spline curves, and with C? continuity, if we use 
cubic splines. 


The following G code can be used for several kinds of spline surfaces, including 
Akima splines, cubic splines and also the approximating B-splines, which we will 
discuss in the next section. 


#define CUBIC_SPLINE 1 (—> Macros.h) 
#define B_SPLINE 2 (— Macros.h) 
Global Init_f ptr(calc_spline_curve, cubic_spline_curve); (—> Proto.h) 
fe eee eee 
void ptr_to_calc_spline(type) (— Proto.h) 


short type; 
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{ /* begin ptr_to_calc_spline() */ 
switch (type) { 


case AKIMA: 

calc_spline_curve = akima_spline_curve; break; 
case CUBIC_SPLINE: 

calc_spline_curve = cubic_spline_curve; break; 
case BSPLINE: 

calc_spline_curve = b_spline.curve; break; 


} /* end ptr_to_calc_spline() */ 


void calc_spline_sur face(m, result, ctrl_point, n, span_size, type, k) 
(— Proto.h) 


short m[2]; /* Size of the surface. */ 

Vector +*««*result; /* Address of 2d-array. */ 

Vector *«ctripoint; 

short n[2]; /* Number of control points. +/ 

short **span_size; 

short type; /* AKIMA, CUBIC_SPLINE, B_SPLINE etc. */ 
short k[2]; /* This is only for B-spline surfaces. */ 


{ /* begin calc_spline_sur face() */ 
register short 1, 7; 
register float +21, *z2; /* Necessary for the macro Fast_copy(). */ 
static Vector **surface = NULL; /* The desired surface. */ 
Vector **auz_surf, /* Auxiliary surface. */ 
Vector *auz_ctrl: 


ptr_to_calc_spline( type) ; 
/* Determine size of surface */ 
m[0] = m[1] = 1; 
for (i= 0;i< n[0]; #++) 
m[0] += span_size [0] [4]; 
for (i= 0; i< n[1]; +++) 
m[1] += span_size [1] [4]; 
/* Allocate surface «/ 
Alloc_2d_array( Vector, surface, m[0], m[1]); 
*result = surface; 
Alloc_array(Vector, auz_ctrl, n[0], "tmp") ; 
Alloc.2d_array( Vector, auz-surf, n[0], m[1}); 


/* Calculate aux_surf */ 
for (i= 0;1< n[0]; i++) 
calc_spline_curve(&m[1], auz_surf [4%], 
n(1], ctri_point[i], span_size[1], k[1]); 
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#+define Fast_copy(b, a) \ (local macro) 

t2 = (float *) b, x1 = (float *) a,\ 
*e2++ = *21+4+, *22+4+ = *714+4+, *22 = *71 
for (j = 0; 7 < m[1]; j++) { 

for (i = 0; 7 < n[0]; +++) 

Fast_copy( auxz_ctrl{i], auz_surf |<] [7] ) ; 
calc_spline_curve(&m[0], surface [j], 
n(0], auz_ctrl, span_size[0|, k[0]); 


Free_array(auz_ctrl, "aux_ctr1"); 
Free_2d_array( auz_surf) ; 
} /* end calc_spline_sur face() */ 


9.2 Approximating Curves and Surfaces 


For many applications, the use of “approximating splines” (and approximating 
spline surfaces) is advisable, because they do not necessarily have to contain the 
control points. For example, if we use control points that are not very reliable, 
and if we know, however, that the curve they should belong to is smooth, it is 
a good idea to use approximating splines. They can also be very helpful if we 
simply want to create objects with smooth shapes. 


Approximating Splines 





FIGURE 4. Approximating spline curves (B-splines). 


Several kinds of approximating splines have been developed, among them the 
Bezier-splines, the B-splines [FOLE90] and the (-splines ([BARS88]). For our 
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purposes, we only need the so-called B-splines. They are given by the parametric 
equation 


E(t) = > bin (t) Gi, (12) 
i=0 


where Qo, 91, ---, dn are the n + 1 control points. The index k = 2,3,..., deter- 
mines the number of control points that have an influence on the points of the 
curve. The curve is then C*~? continuous, i.e., we have C? continuity for k > 4. 


33332 


FIGURE 5. B-splines with different continuities. 


i 


On the parameter interval 0 < t <n—k-+ 2, we define the constant values 


0 ifi< k; 
a= fink ifk<i<n; (13) 
n—k+2 otherwise, 


which lead to the knots (breakpoints) C; of the n —k+ 2 spans of the curve. The 
coefficients b;,(t) of an arbitrary curve point belonging to the parameter ¢ are 
defined recursively by means of the constants c;: 


We start with 


= 1 if co; <t < C4413 
bia (t) = ‘0 otherwise, (14) 


and then we calculate b;,2 6;,3,..., 0:4 as a weighted linear combination of the 
coefficients of lower degree: 


t—G Cat 


b; ;(t) = bi,j-1(t) + 


= bi+1,;-1(t). (15) 
Ci+j—-1 ~ Gi Cit 5 — Cit] 
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Only inside k intervals are these coefficients non-vanishing. Therefore, calculation 
time increases only linearily with the number of control points. 


Figure 5 shows typical B-splines. For k = 2, the spline will be the polygon itself. 
For k = 3, all the line segments Q;Q;41 will be tangents of the curve. For k > 3, 
this is only true for the first and the last spans of the polygon. If we want to 
force the B-spline to get closer to a control point Q;, we count Q@; more than 
one time. (If we count Q; k times, the curve will go through Q,;. In this case, 
however, the curve will have a sharp bend, which is not what we usually want.) 


Points on the curve can be calculated by means of the following C code: 


a 
void b_spline_coef f(b, t, n, k, c, 71) (— Proto.h) 
float + +b; 
float t; 
short n, k; 
short *c;  /* B-spline constants. +/ 
short i1; 


{ /* begin b_spline_coef f() */ 
register float + b_ij; 


register short 7, 7, *ci, *C 
float *mazrb = &b[n + 1][0 at: 
short delta-b = 6{1] — 0(0); 
short 10; 


&clil]; 
for 04 = inl bij < maz_b; bij t= = delta_b) 
bij = («ct < th&t<= *++ci) ? 1: 0; 


for (j = 1,3 <_k; j++) 
t= il; cd = &clil]; qe=cat j; 
for e = Soy + "i bij < max_b: bij += delta_b) { 
bij [3] 
bijx= ad i /(*cj — et); 
te fi) a+ 
ty + = (ej —t) /(xcj — *ci) * dfi][3]; 
} /* end for (bij) */ 
} /* end for (i) */ 


Bis is the “readable code”: 
for A at n; +) 
if ‘sth yo thee t e oi + 1]) bfi|[1] = 
for GG = = 2; J <= &; i+ 
bial] = (= a we é+ gj —1]—cfi]) + bfa]lj — 1+ 
/x end for (i) +/ (cle+ 3] —t) /(clit+ 9] —cli+1)) *bh+ 1 — 1); 


}  /* end b_spline_coef f() */ 
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#define Zero_vec(v) (v)[X] = (v)[Y] = (v)[Z] = 0 (—> Macros.h) 


void b_spline_curve(no-of -_vertices, curve, n, q, span-_size, k) 
(— Proto.h) 
short +*no_of_vertices; 

Vector curve| |; 

short 7; 

Vector q| |; 

short ¥* span_size; 

short k; 


{ /* begin b_spline_curve() */ 
register short *c; 
register short i, j; 
float t, dt, r; 
float x xb; 
Vector *curve0 = curve, *q1; 
short i1, 12, 73; 


Alloc.array(short, c, n + k, "coeff"); 
Alloc2d_array(float, b, n + 1, k + 1); 


/ * B-spline constants * / 


t= 0; j = ; 
while (i< k) 
cli++] = 0; 
while (i< n) 
cit++] = j+4; 
while (i< n + k) 
cit +] = 5; 
t= k -1;i1 = i-—(k-1); 12 = i+ (k-1); 


for (;i< n+ 1; i++4, i1++4, i2+-4) { 


t= i, + EPS; 

dt = (cli+1] ~t) [(*span-size) — EPS; 
i1 = Mazimumi(il, 0 

i2 = Minimum(i2, n); 


j = 0; 7 < xspansize; j++, t+= dt, curve+ +) { 
if ((== EPS) { 
Copy-_vec(*curve, q[0}); 
}else { 
if (j == 0|| dt > EPS) 
b_spline_coef f(b, t, n —1, k, c, 11); 
Zero-vec( reurve) 


—~ 


for 


for (i3 = il, q L = 9g + al; i3 < i2; i3++, gl1++) { 
if ((r = bh |) != 0) 
*xcurve)[|X] += rx* (*q1) ai 
xcurve)|Y| += rx (*q1)/Y 
(*curve)|Z| += r* (*q1)[Z 











} /* end if (r) */ 
} /* end for (43) */ 
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} /* end if (t) */ 
} /* end for (7) */ 
span_size + +; 
} /* end for (i) */ 
Copy_vec(*xcurve, q|n — 1}); 
* no_of_vertices = +-+curve — curve; 


Free_mem(c, "coeff"); 
Free_2d_array(b); 
}  /* end b_spline_curve() */ 


Approximating Surfaces 


A very important application of approximating splines is the creation of smooth 
shapes. For this purpose, we extend the definition of the spline curve to the third 


dimension: 


ni ne 


E(u, v) = D> di,ks (4) By, (v) Gy. (16) 


i=0 j=0 





FIGURE 6. B-spline surface given by a grid of control points. 


The vectors gj; are the position vectors of the (n; +1) (n2+1) control points Qi; 
(Figure 6). Note that we now have two indices k, and kg in the u- and v-directions 


9.3 
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(so that we have two degrees of freedom). Lines of constant u (v-lines) are B- 
spline curves with the control vertices 


Gav) = Sdjug (0) diy. (17) 


i=0 


Bach of the nj + 1 given v-lines may consist of me vertices Vij. The ny + 1 
vertices V;;, that belong to the same index jg are control vertices for ma u-lines 
(among them the given ones). In the same way, we can determine m  v-lines. 
The surface finally consists of m; m2 vertices. The given n, nz patches are joined 
together with C*™ (C*) continuity. 


The C code for the calculation of B-spline surfaces is included in the function 
calc_spline_sur face(). 


Special Curves on Polygonized Surfaces 


In practice, many surfaces are given only by a limited number of points, as in 
the case of measured data. It is often necessary to find special curves on such 
surfaces. In this section, we will show that, in many cases, it is possible to get 
useful results without replacing the polyhedron by spline surfaces. 


The Polygonization of Surfaces 


We assume that we have at our disposal a certain set of points on the surface. 
The coordinates of these points can either be measured data (e.g., in the case of 
a terrain), or they can have been calculated by means of mathematical formulas. 
If the number of these points is comparatively small, we can also add new points 
by spline interpolation. If we want to have points at a particular place of the 
surface, such as above a grid on the base plane (e.g., to be able to use the fast 
hidden-surface algorithms described in Chapter 5), we have to calculate these 
new points by interpolation. 


Then we triangulate the surface by connecting three neighbor points, each to a 
triangle (face). In general, each face has three neighboring faces. All the triangles 
taken together form a polyhedron, which approximates the surface more or less 
satisfactorily, depending on how detailed the dissection has been. Another kind 
of polygonization that can be used for implicit surfaces is described in [BLOO87]. 


Example 1: Contour Lines. We replace the contour of a surface by that of 
the approximating polyhedron, which is composed of specific edges of the 
polyhedron. Each face has a normal vector. We assume that the surface can 
be oriented and that all the normals point to the same side of the surface. 
With reference to a given perspective we can now distinguish between two 
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types of faces: those, where the normal vectors are inclined towards the 
projection center, and the others, where this is not the case. For solid objects, 
they are called frontfaces and backfaces (Chapter 5). Two triangles of a 
different kind have one edge of the contour polygon in common. 


Consequently, we check for each face, whether the angle enclosed by the 
projection ray and the oriented normal of the face is smaller or greater 
than 3. Then we compare the type of each face with that of its neighboring 
faces. The contour line of a surface is particularly useful for plotter drawings, 
especially when we do not want to display too many images of parameter 
lines. 
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FIGURE 7. Contour lines and lines of intersection of function graphs. 
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If we replace the contour line of a surface by the contour polygon of an 
approximating polyhedron, we usually get reasonably accurate pictures with 
a minimum of calculation time. The reason for the good correspondence 
between the contour lines lies in the fact that the faces that carry the edges 
of the contour polygon are nearly projecting (i.e., the image of the polygon 
is almost a straight line). This means that the deviations of the image of 
the contour polygon of the approximating polyhedron from the image of the 
contour of the surface are reduced to a minimum, even though the respective 
lines may have completely different positions in space. 


Example 2: Isophotes. Analogously to Example 1 we can trace the lines of 
equal illumination. Again we divide the faces of the approximating polyhe- 
dron into two kinds: those where the angle enclosed with the light ray is 
smaller than the prescribed angle of inclination, and those for which the 
opposite is true. The polygon though, which represents the set of edges that 
two faces of different type have in common, does not approximate the actual 
isophote very well in the projection onto the screen because, in most cases, 
the faces that carry the edges are not projecting at all. In order to get nice 
pictures, we can still apply spline interpolations to the projections of the 
polygons. These interpolations, however, are not always reliable enough, 
so that sometimes we have to resort to more precise but slower methods 
([LANG84], [POTT88}). 


Example 3: Lines of Intersection. The approximation of surfaces by means 
of polyhedra is a very good method of dealing with intersections. Instead 
of applying the time-consuming algorithm described in Section 8.2 (Exam- 
ple 3), we simply check for all the faces of the polyhedron on which side 
of the intersecting surface they lie. Most of the faces will not penetrate the 
intersecting surface. For the few faces on which a part of the vertices is on 
a different side of the intersecting surface than the other part, we simply 
consider the straight line between the two intersection points of the edges of 
the (always convex) face as a part of the line of intersection. If the number 
of faces is small, we can smooth the intersecting polygon by means of spline 
interpolation. 


Figure 7 shows the lines of intersection of a function graph, which were men- 
tioned in Section 8.2 when we tried to get arbitrary curves on mathematical 
surfaces as the solution of a function f(u, v) = 0. 


9.4 Spatial Integral Curves 


In addition to the parametrized curves = X(t) on surfaces and the curves that 
fulfill a condition f(u, v) = 0, there are other interesting curves on surfaces: the 
solution curves of vector fields. They are characterized by a differential equation 
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in u and v, for which we have an infinite number of solution curves on the surface 
(e.g., the lines of steepest slope). Let us assume that in each point of the surface, 
the tangent vector of the corresponding curve is known so that the direction 
dv : du of the line of solution is given. We now want the computer to calculate 
the integral curve of the vector field. The direction of the curve is indicated by the 
tangent vector in the tangent plane, which can be given as a linear combination 
of the tangent vectors of the parameter lines through the point (these vectors 
are the difference vectors Z, and Z, in Equation 25): 


te Lu Ly 
t=2Z,.du+2Zz,.dv or ty }= | Yu | dut+ | yw | dv. (18) 
t, Zu zy 


Thus, a point that is close to the point with the position vector ¢ = (u, v) has 
the position vector £(u + €.du, v + ¢.dv). The closer the points lie together, the 
more likely it is that the graphically integrated curve really corresponds to the 
actual lines of solution of the vector field. A branch of the curve ends when the 
parameter values belonging to the point are outside the rectangular domain of 
definition, or when one, while still proceeding in the same direction, comes back 
to the starting point (i.e., when the curve is closed in a circle). 


If the vectors t, Z,, and Z, are given, the parameters du, dv in Equation (18) 
can be evaluated by 


du = Ye atv te dy = yturteYu 


D D (with D = Ly Yy — Yu Lv); (19) 


provided that the determinant D does not vanish. (Otherwise we use another 
pair of coordinate equations in Equation (19)). 


A pseudo-code of the relevant part of the program might look like this: 


Starting point Po := Z(u, v) 
Determine normalized tangent vector to in Po 


P = Po 
t := to 
repeat 


determine tangent vectors 7,,, 2, of parameter lines 
determine du, dv from 2%,, Z, and t (Equation (19) 
u:=uté.du,v :=ut+e.du 
P := <£(u, v) 
determine normalized tangent vector t in P 
until (u, v) outside domain of definition V 
(distance(new point, P_0) < e A angle(t, tp) small) V ¢ is not real 


For accurate results, the factor ¢ has to be very small. On the other hand, it 
should not be too small, for that would increase calculation time. 


After these general considerations, we will now give two examples of how we can 
find the tangent vector t for specific families of curves: 
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Example 1: Loxodromes. Loxodromes are lines that intersect a given family 
of curves on a surface (e.g., a family of parameter lines or the section lines) 
at a constant angle a. 


Through each point of the surface goes one curve of the given family, the 
tangent of which may be interpolated by the straight connection between 
two neighbor points. If we normalize the corresponding direction vector and 
rotate it about the normal of the surface by the constant section angle a, 
we get the desired tangent vector ¢ of the loxodrome. Special cases of loxo- 
dromes are the lines of steepest slope, which intersect the lines of intersection 
orthogonally. 


Example 2: Generalized Helices. Generalized helices are those curves on a 
surface that have constant angles of elevation. If the normal vector of the 
surface has the components 71 = (nz, Ny, Nz), the direction of the horizontal 
tangent has the components h = (—ny, Nz, 0). The vector product 


> 


f=nxh=(-ngnz, —nynz, 2 +n?) (20) 


determines the direction of the tangent with the greatest possible angle of 
elevation, the so-called tangent of steepest slope. Any other direction of a 
tangent is then a linear combination of the two vectors h and f: 


: . —Ny — ANz Nz 
t = (tz, ty,tz) =h+Af=| ne-Anyn, |. (21) 
(n2 + n2) 


If ~ is to have the constant angle of elevation 3, we have the condition 


n2 +n? 
tan B= 2 = yf Pe (22) 


which leads to a quadratic equation in A. Every real solution 


tan B 


,/n2 +n —n2 tan 2B 


h=t (23) 


determines a tangent vector f. 


Let us now extend the method for the determination of the integral curves of di- 
rection fields to approximating polyhedra. Of course, there is no more guarantee 
for perfect accuracy, but we have to consider that sometimes there is no other 
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way to get such curves. Apart from that, the proposed algorithm is comparatively 
fast. 


We assume that, for each face, we can determine a real or not real direction 
vector of the field. In the case of generalized helices, for example, this is — similar 
to Example 1 in this section — the tangent vector that has a constant angle of 
elevation with respect to the base plane. Let us start from a point A at the inside 
of a face (Figure 8). 


The straight line that is determined by the point and by the direction vector of 
the face may be called the field line through A. (For certain applications, e.g., 
for trajectories, this line has to be oriented.) It intersects the border of the face 
in two points A,, Ag. The edge between these two points is stored as a part of 
the “integral polygon.” A; and Ag lie on edges the face has in common with 
two neighbor faces. We now continue the polygon in the directions of both these 
neighbor faces until we reach a criterion to break off the search. 





FIGURE 8. The search algorithm for “integral polygons” on approximating 
polyhedra. 


Naturally, the vertex of our first edge also lies on an edge of the neighbor face 
and, together with the direction vector of this neighbor face, it determines a 
new field line. We determine the residual section point R of this line with the 
neighbor face. If there is another face on the polyhedron that shares the edge 
through R with the current face, we can apply the same procedure once more. If 
there is no other neighbor face on the polyhedron or if the polygon is closed, we 
break off the search for more points. Since all the problems that are described 
here can be solved by simple methods of analytic geometry, without the use 
of time-consuming mathematical functions like sine or tangent, we may assume 
that the algorithm will be done very quickly. 


A pseudo-code illustrates the problem even more clearly (compare with the 
pseudo-code at the beginning of this section): 
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Choose starting point inside an arbitrary face fo 

Intersect the corresponding field line with the border of the face 
Determine the (in general 2) neighbor faces (starting faces) 

for all starting faces 


previous face := fo 
current face := starting face 
repeat 


residual section point R of field line with current face 
if neighbor face through R exists 
previous face := current face 
current face := neighbor face 
until no more neighbor face V polygon closed V field direction not real 


In this way, we can again trace loxodromes, orthogonal trajectories, generalized 
helices and many other curves on surfaces. 


9.5 Some Examples of Applications 


Example 1: “Landscapes.” The algorithms described in the previous sections 
can easily be applied to landscapes, which of course do not submit them- 
selves to mathematical rules. A partial approximation by means of math- 
ematical surfaces may be acceptable, but does not necessarily correspond 
to reality. Therefore, the simple approximation by a polyhedron is justi- 
fied as well, especially if one completes the number of measured points by 
means of spline interpolation — preferably done by the AKIMA-interpolation 
([(PURG85]), which is indifferent to the multiple differentiabilty of the sur- 
face. 


Provided that the terrain does not have any overhanging rocks, the surface 
may be interpreted as a function graph above a two-dimensional domain of 
definition (usually a rectangle). If the normal projections of the measured 
points of the surface onto the ground plane do not belong to a grid, we 
interpolate the spot heights of the grid points in order to be able to use 
specific hidden-line or hidden-surface algorithms ([GLAE88/1], [HEAR86}). 


Then we triangulate the surface by splitting the skew patch above four 
adjoining grid points into two triangles. We can now apply all the algorithms 
of the previous sections to the approximating polyhedron. Of course, the 
lines of intersection are of great importance. The contour line is very useful 
for plotter drawings. The generalized helices on the surface are important 
for the construction of roads with constant angle of elevation. 


Of particular interest to biologists and forestry engineers are the lines of 
steepest slope, along which rain water, and also, avalanches and landslides, 
will seek their way (Figure 9). 
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Example 2: Potential Areas. The author was motivated to write this section 


when dealing with the problem of how to find the equipotential lines and 
field lines of electrical potential areas. From the geometrist’s point of view 
this is nothing but the tracing of lines of intersection and their orthogo- 
nal trajectories on function graphs. In the top view, these lines form an 
orthogonal net. Figure 9 shows such a surface, given by the equation 






—1 
e— oa (z real, w= az + ty complex) (24) 
ie Meio 
(+2 x? + y? +14 2x (25) 


The normal projections of the equipotential lines and field lines on the 
ground plane are, as is well known, two orthogonal pencils of circles. The 
results of the integrations of the curves can hardly be distinguished from 
the accurate solutions of the differential equations. 








FIGURE 9. Equipotential lines and field lines on an electrical potential area. Their 
normal projections on the ground plane are two orthogonal pencils of circles. 


10.1 


10 


Computer-Generated Movies 


In the previous chapters, we saw how it is possible to create realistic computer- 
generated images and how we can manipulate a scene by way of changing the 
position of its eye point. In this chapter, we will develop subroutines that permit 
us to store the frames of a movie efficiently in a “video file.” 


We will introduce a new program (a “movie previewer”) that reads this file 
and replays it as quickly as possible. Such a file is independent of the hardware 
that is used so that it can be replayed on any graphics computer. On graphics 
workstations with fast graphics hardware, this previewer may be so fast that the 
whole movie can be displayed on the screen in real time, so that we just have to 
position a film camera in front of the screen and to record the scene. (In fact, 
this is probably the most economical way of producing a computer-generated 
movie.) If we do not have such a sophisticated workstation at our disposal, we 
can still record the movie frame by frame. 


An Economical Way of Storing a Movie 


Our graphics program package produces two kinds of output: a set of lines (wire 
frames) and/or a set of filled polygons (shading and shadows). 


Usually, we build our frames by plotting the image polygons in the correct order 
(with the exception of depth-buffered polygons). It turns out to be much more 
efficient to store the information about the polygons rather than to store the 
screen pixel by pixel. What is even more, the storing of polygons makes us 
independent of the screen resolution. 
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Our final goal is to be able to transfer the stored movie to any other computer 
(even to one that has only a minimum of graphics facilities) and to replay it 
there without having to change anything. In this way, the quality of the output 
can be improved if we switch to a more sophisticated graphics computer. (Of 
course, we can also store our images in other standards like the IF F-standard, 
but in our special case — we only store polygons — this is the most economical 
way.) 

Let us try to store a movie in such a way as to make it fully compatible with other 
graphics computers. We will distinguish between 8-bit integers intg (chars), 
which are in the interval Ig(0 < intg < 2°), and 12-bit integers inti2, which are 
in the interval I}2(0 < inti2 < 2!2). Numbers of different type will be stored in 
different files so that no disk space is wasted. 


First we predefine some numbers: 


#define MAX_12_BIT (short ) Orff — Macros.h 
#define NEW_FRAME (MAX8_BIT — 1) — Macros.h 
#define END._MOVIE AX 8_BIT — Macros.h 


Numbers of the type intg are stored in the file "<filename>.vdi", numbers of 
the type inti2 in the file "<filename>.vd2". While switching from one output 
file to another (depending on the type of the number) we store | 


1) the characteristic [D-number 
(ints) MAX_8_BIT, (inti) MAX_8_BIT 
at the head of each file, so that the 
computer can recognize the files as a “movie.” 
2) the Boolean expressions 
ints) Smooth_shading. 
(If TRUE, the polygons have to be smooth-shaded.) 
3) the active palettes as follows: 
intg) palette_indez, 
intg) lower RGB values rl, g1, 61 (transformed into Ig) 
intg) upper RGB values r2, g2, 62 (transformed into Ig). 
4) one frame after the other, starting with the keyword 
(ints) NEW_FRAME. 
Now we store the Bool variable 
(intg) New_image, 
which indicates whether the current frame differs from the previous one. 
(In a movie an image may be “frozen” for a while. It would be 
a waste of disk space to store the same image several times.) 


If New_image is TRUE, we store all the polygons in the following way: 
ints) number n of vertices 

intg) color (palette index), 

intg) if Smooth_shadin 

(intg) shade of color (transformed into Ig) 


(intg) n shades of color (transformed into Is) 
(inty2) n pairs of normalized device coordinates 7, y 
(transformed into Ij.) 
5) the 
(intg) END_MOVIE 
constant. 
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Numbers of the type ints are efficiently stored as characters by means of the 
C macro putc() and re-read by means of the macro getc(). 


To store 12-bit integers, we use fast bitwise operators, which pack eight such 
numbers into three long variables (with 32 bits each). Figure 1 shows how the 
function pack_or_-unpack_96_bits() works. 


12 bits | 


x00! | xi11 x12) | x31 | x14) | X51] | x6) | xt7/ 
Ty tT ET TET ULE TL ET ETT EET 


nto] 





96 bits 
FIGURE 1. How to pack eight 12-bit integers into three long variables. 
typedef unsigned long Ulong; (— Types.h) 
| 
void pack_or_unpack_96_bits(n, 2, pack) (— Proto.h) 
Ulong n/[3], «[8]; 
Bool pack; : 
{ /* begin pack_or_unpack_96_bits() */ 
if (pack) 
n{0] = (x[0] «< 20) | (z[1]« 8) | (z[2] > 4), 
n{1] = ((a[2] & Oxf) «< 28) | (x[3] « 16) 
(ald) <«< 4) | (2[5] > 8), 
n[2] = ((a[5] & Orff) <« 24) | (x[6] «< 12) | 2[7]; 
else 
z[0] = (n[0] & Oxf ff00000) >> 20, 
z[1] = (n[0O] & Ox000fff00) > 8, 
z(2] = ((n[0] & Ox000000ff) <«< 4) | ((n[1]& 0xf0000000) >> 28), 
z[3] = (n[1] & Ox0fff0000) >> 16, 
x4] = (n[1] & Ox0000f ff0) >> 4, 
z{5) = ((n{1] & 0x0000000f) < 8) | ((n[2]& Oxf f000000) >> 24), 
x6] = (n[2] & Ox00fff000) >> 12, 


z{7] = (n[2] & 0x00000f ff); 
}  /* end pack_or_unpack_96_bits() */ 
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A 96-bit block is put into a binary file by means of the function 


FILE « Video-file{2); (— Globals.h) 
/* Must be initialized by Video_file[0] = NULL. «/ 


CT 
void put_or_get_96_bits(c, put) (— Proto.h) 


register char * C; 
Bool put; 

{ /« begin put_or_get_96_bits() */ | 
register char * hic = c+ 12; /« sizeof(c[12]) = 96 bits. */ 


if (put) 
for (; c< hic; c++) 
putc(*c, Video-_file(1]); /* C macro! */ 
else 
for (; c< hic; c++) 
*c = getc(Video_file(1]); /* C macro! */ 
}  /* end put_or_get_96_bits() */ 


An example will show how efficient this kind of storage is. A scene of medium 
complexity may consist of 300 polygons (quadrilaterals, for example). To store 
a quadrilateral, we need three 8-bit integers and eight 12-bit integers, i.e., 120 


bits or 15 bytes. 


Thus, a frame requires only 4.5 Kbytes! A real time movie of ten seconds and 
with 250 frames can be stored in a file that has a size of little more than one 
Mbyte. If the polygons are smooth-shaded (e.g., when we store a smooth-shaded 
surface of revolution), we need about 20% more space. 


Let us start our graphics package. By means of an additional option, we tell the 
program that we want to store the images. This can be done by writing: 


progname <datafile> -v <videofile>. 
in the command line (see Appendix A.3). 
A flag | 
Bool Init(Storeimage, FALSE); (— Globals.h) 


is then set TRUE. When we create the color palettes, we open the video file and 
store the information on the palettes that are going to be used. For this purpose, 
we add the following lines at the beginning of the function create_palettes(), 
which was described in Section 4.3. 
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#ifdef ANSI 

# define READ_BIN "rb" (—> Macros.h) 
# define WRITE_BIN "wb" (—> Macros.h) 
#else 

# define READ_BIN "r'" (— Macros.h) 
# define WRITE_BIN "w" (— Macros.h) 
#endif 


/* This may be tricky. The standard C language does not distinguish between 
binary files and text files. This will lead to problems, if you work in the 
DOS environment, where a file is closed by the character < Ctrl > z. 
(In a UNIX environment no EOF flag is set.) You should write a short 
test file to figure this out. */ 


#-define Send_8_bit_int(n)\ (— Macros.h) 
putc((Ubyte) (n), Video_file[0)) 
#-define Send_12_bit_int(n)\ (— Macros.h) 


send_12_bit_int((short ) (n)) 


if (Storeimage && !Video_file|0|) { 
Video_file[0| = safe_open("<filename>.vdi", WRITE_BIN); 
Video. file[1] = safe_open("<filename>.vd2", WRITE_BIN); 
Send_8_bit_int(MAX_8_BIT); 
Send.12_bit_int(MAX_8_BIT); 
Send_8_bit_int(Smooth_shading); 
init_video_buffer(); /* This function will be explained soon. */ 
} /* end if (Store_image) */ 


At the end of the function make_spectrum() (Section 4.3), we send the index of 
the palette and its characteristic RGB values to the file: 
if (Storeimage) { 
n=pal — Parent_palette; 
Send 8_bit_int(n); 
Scale_vec(rgb, pal—>lower_rgb, MAX_8_BIT); 
for (n=0; n < 3; n++) 
Send_8_bit_int(rgb|n)); 
Scale_vec(rgb, pal—>upper_rgb, MAX_8_BIT); 
for (n=0; n < 3; n++) 
— Send_8_bit_int(rgb[n)); 
} /* end if (Store_image) */ 
A function send_12_bit_int() receives a short between 0 and Ozf ff = 2} -1= 


4095 and integrates it into a field that is 96 bits long. As soon as eight shorts 
have been buffered, the bit field is sent to Video_file[1]. 
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void send_12_bit_int(s) (— Proto.h) 


{ 


j 


short 3s; 


/* begin send_12_bit_int() */ 

static Ulong buffer[8]; /* Buffered numbers. +/ 

static Ulong space[3];  _/* Reserves 96 bits. +/ 

static short 1 = 0; /* How many numbers in buffer. */ 


if (s > 0) 
bufferit+] = 8; 
else /* Flush buffer. */ 
while (i < 8) 
buffer[it+] = 0; 
if (i == 8) 
pack_or _unpack.96_bits((char *) space, buffer, TRUE), 
put_or.get_96_bits(space, TRUE), 
a= 0; 
/* end send_12_bit_int() */ 


In the next section, we will need the reverse function receive_12_bit_int() to 
extract the compressed numbers from the file: 


short receive_12_bit_int() (—> Proto.h) 


{ 


/* begin receive_12_bitint() */ 

static Ulong buffer|8];_ /* Buffered numbers. */ 
static Ulong space[3]; | _/* Reserves 96 bits. */ 
static short i= 7; 


i= ++i % 8; 
if (i ==0) 
put_or_get_96_bits(space, FALSE), 
pack_or_unpack_96_bits((char *) space, buffer, FALSE); 
return (short ) buffer|i|; 


} /* end receive_12_bit_int() «/ 


Every time a polygon (or a line) is drawn, the coordinates of its vertices are sent 
to a buffer. For the respective code, we introduce a new type and some variables, 
which are global in the current module. 
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typedef struct { 

Ubyte no-of _vertices; 

Vector2 * vertices; 

Ubyte color, shade; 

Ubyte * smooth_shade; 

short xrmin, xmaz, ymin, ymaz; 

float area; 
} Poly2d; (— Types.h) 
Poly2d x All_polys, *Cur_poly2d, +Hi_poly2d; 
Vector2 * Vbuffer = NULL, *Curv = NULL; 
short No.of -_saved_frames = 0; 
Ubyte * Shade_pool, «Cur_s; 


#define MAXPOLY 3000 (local macro) 
#define BUFSIZE 20000 (local macro) 


The buffer is initialized for the first time when we open the video files. (It will 
be reinitialized every time a frame has been stored.) 


void init_video_buffer() (— Proto.h) 


{ /x begin init_video_buffer() */ 
if (!Vbuffer) { 
Allocarray(Poly2d, All_polys, MAXPOLY, "vbut"); 
Alloc-array(Vector2, Vbuffer, BUFSIZE, "vbuf"); 
if (Smooth_shading) 
Alloc_array(Ubyte, Shade_pool, 4 * MAXPOLY, "smooth"); 


Curv = Vobuffer; 
Cur_poly2d = All_polys; 
Cur_s = Shade_pool: 

}  /* end init_video_buffer() */ 


When we buffer a polygon (or a line), we have to make sure that the polygon 
(line) has been clipped! The polygon has to be stored in an array of Vector2s. 
When the polygons are smooth-shaded, the shades have to be stored in an array 


Ubyte Shades_of.vertices| MAX_POLY_SIZE): (— Globals.h) 


When plain shading is applied, the current palette and the current shade have 
to be stored by means of the global variables 


Ubyte Cur_shade, Cur_palette, Cur_poly_color, (— Globals.h) 
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void buffer_line(p, q) 


{ 


} 


Vector2 p, 4; 


/* begin buffer_line() */ 
register Poly2d *cp = Cur-_poly2d; 


cp->color = Cur_palette; 
cp-> shade = Cur_shade; 
cp—>no_of vertices = 2; 
cp->vertices = Cur_v; 
Copy-_vec2(*Cur_v, p); Curv+4; 
Copy_vec2(*Cur_v, q); Curv++; 
Cur_poly2d++; 

/* end buffer_line() */ 


void buffer_polygon(n, vertices) 


short n; 
Vector2 * vertices; 


/* begin buffer_polygon() */ 

register Poly2d *p = Cur_poly2d; 

register short 72, 4; 

register Vector2 *v, hiv = vertices + n, *v1; 


p->no.of vertices = n; 
p->color = Cur-_poly_color, 
if (!Smooth_shading) 

p—>shade = Cur-shade; 
else { 

p—>smooth_shade = Cur-.s; 

for (cx = 0; x < n; x++) 

* Curs++ = Shade-of-vertex[z]; 

} /* end if (Smooth_shading) */ 
p—->vertices = Cur_v; 


/* Store vertices in buffer. «/ 
for (v= vertices; v < hiv; v++, Cur_v++) 
Copy-vec2(+Cur_v, *v); 


/* Bounding rectangle of polygon. */ 
v= vertices; 

p>axmin = p>axmazx = (+v)[X]; 

p>ymin = p->ymar = (xv)[Y]; 


(— Proto.h) 


(— Proto. h) 
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for (v= vertices + 1; v< hiv; v++) { 
x = («v)[X]; y = (+v)[¥]; 
if (x < p->xmin) p>szrmin = 7; 
else if (cx > p—>zmaz) p>rmar = 7; 
if (y < p>ymin) p>ymin = y; 
else if (y > p—>ymaz) p>ymaz = y; 
} /*x end for (v) */ 


/* Area of polygon. */ 
p->area = Q; 
for (v= vertices +1, vl = v+ 1; vl < hiv; v+4+, vl++) 
p->area + = fabs(Area_of 2d-triangle(*vertices, *v, *v1)); 
if (p—>area > 4) Cur_poly2d++; 
} /* end buffer_polygon() */ 


When the screens are swapped, we simply flush this buffer. Some of the polygons, 
however, may have been completely erased during the drawing process. Thus, it 
is worthwhile to check whether a polygon really has to be drawn. Even though 
this takes some computation time, it will both save space and — what is even 
more — reduce the replay time. 


Bool Init(New-image, FALSE); (—> Globals.h) 
rr 
void release_buffer() (— Proto.h) 


{ /« begin release_buffer() */ 
register Poly2d * 7p; 
register Vector2 *v, *hi_v; 
short i, total, n; 
static float scale_ry = 0, scale_shade; 


if (!scale_cy) 
scalery = 4096/Mazimum( Window-_width, Window_height), 
scale_shade = (float) MAX_8_BIT / PAL_SIZE, 
Send 8_bit_int(NEW FRAME); 
if (!New_image && No-of-saved_frames > 0) { 
Send_8_bit_int( TRUE); 
No.of .saved_frames++; 
return ; 
} else 
Send_8_bit_int( FALSE); 
Hi_poly2d = Cur_poly2d; 
if (Hi_poly2d — All_polys) == 0) 
return ; 
for (p = Allpolys; p < Hi-poly2d; p++) { 
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} 


The important optimizing function necessary .to-plot() will reduce the size of 


n = p->no-_of -vertices; 
if (n > 2 && !necessary_to_plot(p)) 
continue; 
hiv = (v= p—-vertices) + p—>no-of vertices; 
Send 8_bit_int(n); 
Send_8bit_int(p—> color); 
if (!Smooth_shading || n == 2) 
Send_8_bit_int(scale_shade * p—> shade); 
else 
for (i= 0; i< n; i++) 
Send_8_bit_int(scale.shade * p—> smooth_shade(i]); 
for (; v< hi_v; v++) { 
Send_12_bit_int((*v)[X] * scale_ry); 
Send_12_bit_int((*v)[Y] * scale_xy); 
} /* end for (v) */ 
} /* end for (p) */ 
No-of .saved_frames+-+; 
init_video_buffer(); /* Reset the global pointers. */ 
/* end release_buffer() */ 


the file by + 20% (410%): 


Bool necessary-to_plot(p) 


{ 


register Poly2d +p; 


/* begin necessary-_to-_plot() */ 
register 2Poly2d xq, *q0; 
Vector2 + pl; 

Vector2 * which_poly; 

short nl, 2; 

static Vector2 * clipped = NULL; 


if (p->color == NO-_COLOR) 
return FALSE; 
if (!clipped) 
Alloc_array(Vector2, clipped, MAX_POLY_SIZE, "clip"); 
nl = p->no-of-_vertices; 
pl = p->vertices; 


/* Check whether the current polygon is hidden by any of the following 
polygons or by the previous polygon when it had the same color. The 
latter case occurs especially when shadows are plotted on large faces. */ 


(— Proto.h) 
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for (0 = p —1; ; g0—-) 
if (¢qQ—>color != p->color) break; 
for (q = Hi_poly2d —1; q > @0; q——) { 
if (q == p) continue; 
/* A very efficient way of checking whether the polygon is obscured by 
the contours of other objects. */ 
if (q—>color != NO-COLOR) continue; 
/* pcan only be hidden by q if Area(q) > Area(p). */ 
if (p—>area > q—area) continue; 


/* Does the bounding box of q contain the one of p? */ 
if (p>amin < q—->z2min || p>xmaz > q>-2maz || 
p>ymin < q>ymin || p>ymar > q>ymaz) 
continue; 


/* Final decision: intersect polygons. */ 
n2 = q->no-_of vertices; 
if (clip_convex(n2, q->vertices, nl, pl, 
clipped, &which_poly), 2) 
if (which_poly == pl) 
return FALSE, /+ Do not save polygon! */ 
} /* end for (q) */ 
return TRUE; 
} /* end necessary_to_plot() */ 


We must not forget to send the END_MOVIE constant to the stream 
Video_file[0| at the end of the program. Because we always quit the program 
by calling the function safe_ezit() (Section 3.1), we add the lines 
if (Video_file[0]) { 
Send_8_bit_int(END_MOVIE); 
Send_12_bit_int(—1); /* To flush the 96-bit block. */ 
fclose(Video_file[0]); fclose(Video_file[1]); 
} /* end if (Video_file[0]) */ 


to this function. 
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10.2 A Fast Movie Previewer 


The video files that have been created in the described manner can now easily 
be re-read by means of a new program replay.c. Here is the pseudo-code: 


Open video files 
Read (ints) MAX_8_BIT (int;2) MAX_8_BIT for identification. 
Open a back screen and a front screen 
with coordinates 0 < z < 4096, 0 < y < 4096. 
Clear back screen. 
Read (ints) Smooth_shading, palette_index 
while palette.inder #4 NEW_FRAME 
read RGB values (ints) T1, 91; bi, T2, 92; bo 
make palette (linear color spectrum) with shades in [0,255]. 
read (intg) palette_index 
Read (ints) New_image, n 
while n 4 END_MOVIE 
while n # NEW_FRAME 
read n (int,2) pairs of normalized device coordinates 
read (intg) color (palette index) 
if Smooth_shading read n (intg) shades 
else read (intg) shade 
display polygon (line) on back screen in given shade(s) of color 
read (intg) n 
swap screens, clear back screen 
read (ints) New_image 
if not New_image delay 1/30 second 
read (intg) n 


The source code of replay.c is not listed. You can find it on your disk. The 
module has to be linked with several other modules of the programming system. 
Please have a look at the makefile. 
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The Programming Fackage 
our Disk 


The Contents of the Disk 


This book comes with a 31” diskette, formatted under MS-DOS 5.0 with 1,44 
MBytes. You will need a DOS environment to read the diskette. If you work in 
a UNIX environment, you have to transfer the files to your system. 


The disk contains a UNIX version and a DOS version of the graphics package. 
If you work in a DOS environment, call the program install in order to copy 
the contents of the disk to your harddisk. Otherwise, there are a few files that 
you should copy first: a read.me text file and the C files zp.c and uzgp.c. 


The ASCII-file read.me contains information about the installation of the disk 
and about the author and his Email-address — in case you have any problems. 


The disk also contains several directories: 


Directory CODE: It contains the entire source code of the graphics package 
(i.e., the *.c files and the *.h files) except the system-dependent mod- 
ule g-functs.c and the macro file G-macros.h. The code is compressed to 
the file source.zp by means of the file zp and has to be uncompressed by 
means of the corresponding file uzp. 


Directory SYSTDEPS: In this directory you can find the system-dependent mod- 
ule g-functs.c and the macro file G-macros.h plus a makefile for the Sil- 
icon Graphics environment, using the Silicon Graphics Library functions, 
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A.2 





and for the DOS environment, using a WATCOM C compiler. The package 
was developed on Silicon Graphics Workstations: first on the “good old” 
Tris 3020, then on the SG-85 and finally on the Indigo. By means of the 
WATCOM C compiler Version 10.0 it was possible to make the programs 
run in a DOS environment as well. The corresponding files are compressed 
to files named sg.zp and pc.zp. 


A former version of the package used to run on an Impuls Workstation 
(under UNIX) and on the Commodore Amiga (together with the Aztec C 
compiler 3.0). Both versions used to work fine ([GLAE90}). 


If you want to implement the programming package on other graphics com- 
puters, this should be possible if you change the corresponding system- 
dependent macros and the system-dependent functions (see Appendix B). 


Directory DATA: In this directory, some dozens of sample data files are stored. 
The files are compressed to the single file data. zp. 


Directory ANIM: In this directory, a few sample animation files are stored. The 
files are compressed to the file anim. zp. 


How to Install the Program Package 


e You are working in a UNIX environment: 


1. Create a working directory, e.g., FAST3D, and change to this directory: 
mkdir FAST3D 
cd FAST3D 


2. Create the following subdirectories 
mkdir SOURCE 
mkdir DATA 
mkdir ANIM 
mkdir VIDEO 


3. Compile the files zp.c and uzp.c: 
cc Zp.c -o zp 
cc uzp.c ~-o uzp 
4. Copy the file source.zp and the system-dependent code sg.zp into 
the SOURCE-directory and decompress the files: 
cd SOURCE 
../uzp source.zp 
../uzp sg.zp 
cd .. 
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5. Copy the file data.zp into the directory DATA and the file anim.zp 
into the directory ANIM. Then decompress these files in a similar way. 
6. Change to the SOURCE-directory and create the executable files try, 
replay and speed. To do so, just write 
make all 
7. If you work on a Silicon Graphics Workstation, everything should be 
okay now. The executable files are stored in your working directory 
FAST3D. Change to this directory: 
cd .. 
If you do not work on such a workstation, you will have to adapt 


the system-dependent module g-functs.c and the system-dependent 
macros in G_macros.h. 


e You are working on a PC: Switch to the disk-device and write install. 
Then follow the instructions of the installation file. 


If you have a WATCOM C compiler at your disposal, you can recompile 
the files: change to the SOURCE directory and write make all. This calls 
the batch file make. bat that does the job. If you do not want to recompile 
the code, unzip the executable files by means of the widely spread program 
pkunzip.exe (Version > 2.04). If you want to use another C compiler, you 
have to adapt the system-dependent module g-functs.c and the system- 
dependent macros in G-_macros.h. 


Note that the executable programs requires a mathematical coprocessor and 
at least 4 MB RAM (preferably 8MB and more!). 


How to Use the Program 


Once you have managed to compile the package — this will take a while, because 
it consists of dozens of modules — your compiler will create two executable file 
named try and replay in the UNIX environment or try.exe and replay.exe 
in the DOS environment. 


The usage of the program try’ is: 

try <name of a data file> [ options ] 
Valid options are 

-a <name of animation file> 
or 


-y <name of video file> 


1The name try has historical reasons: it took a while until the first data files 
worked, thus each attempt was always a try. 
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To give an example: The command 
try pencil 


starts the program that reads the data file pencil? — a pencil is displayed inter- 
actively on the screen and can be rotated and viewed from any side by means of 
the keyboard: 


draw mode: wire frame, hidden lines 

draw mode: shading, cast shadows 

hidden lines by means of painter’s algorithm 
freeze / auto rotation 

change azimuth 

change elevation 
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> 
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t, T change twist 

x, X enlarge image (decrease fovy angle) 

d, D change distance 

-—-—TJ| | change target point 

1, 2,3 top view / front view / right side view 

4, 5,6 bottom view / back view / left side view 

u undo special view (back to former perspective) 


Additional options are: 

















geocentric / heliocentric 
show color map / undo 
show bounding boxes / undo 

show outlines / undo 

show axes / undo 

show lights (can be changed interactively) / undo 
software z-buffering / undo 

create a PostScript file 

create a video file (default name VIDEO/tmp) 


4 s| quit program 


When we use the the —a option in the command line 






try pencil -a ANIM/pencil 


?The data file should either be in the current directory, or - more clearly — in 
the default directory DATA: the program will automatically look for the file there. 
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the animation is done by the animation file ANIM/pencil. 3 
The command 
try pencil -v VIDEO/pencil 


will store your whole animation in the two files VIDEO/pencil.vd1 and 
VIDEO/pencil. vd2* | 


When you use the the ~a option and the —v option together you can create a 
little movie: 


try pencil -a ANIM/pencil -v VIDEO/pencil 
To replay the movie, type 
replay VIDEO/pencil ® 


Provided you have a fast graphics computer, you have now created your first real 
time animated film. 


How to Write Data Files and Animation Files 


Chapter 3 dealt with the writing of data files. However, this was just an intro- 
duction. The program try can read quite a lot of information. Unfortunately, its 
HELP-options are comparatively poor. The program is not very flexible as far 
as the order of keywords is concerned. 


The best way of learning how to write a data file is to edit the data files Learn. 1, 
Learn.2,..., and to vary it slightly. After a while you check out what you can 
or cannot do. It would fill pages to describe all the possibilities you have. 


The same is true for the writing of animation files. Just edit one of the files 
that are on the disk and make some slight variations. For example, change the 
drawing mode, the number of frames, the eye point and so forth. 


How Fast Is Your Computer? 


The program speed, which you can find on the disk, allows you to test the 
performance of your configuration (compiler plus hardware). 


When we write programs that take a lot of computation time, such as graphics 
programs, it is quite useful to know how fast our computer can carry out various 
tasks. 


3In the DOS environment, the slash has to be a backslash!! This is true for 
the whole section. Furthermore, the directory ANIM is the default directory for 
animation files. 

*The directory VIDEO is the default directory for video files. 

5Since VIDEO is the default directory for video files, you can also write 

replay pencil 
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In this section, we give the listing of a program that is system-independent and 
that can be used for the testing of your machine. 


The test results still depend on the compiler that is used (there are considerable 
differences!) and on the values chosen for the test variables. Nevertheless, the 
program shows which system calls or which library functions can be used without 
any problems and which of these calls would be “bottlenecks” in your programs. 
Here is the listing of the program speed.c: 


#tinclude <stdio.h> 

#include <math.h> 

#tinclude <time.h> /* prototype of clock() */ 
/* 


How fast is your computer? 


This program analyzes how long it takes your computer 
to carry out various tasks, e.g., to multiply two floats 
or to increment an integer or to pass a parameter to 
a function. This enables you to find out the bottlenecks 
in your programs. 

*/ 

#define COMPILER "indigo2" 

#Hifndef LANGUAGE_C_PLUS_PLUS 

# define LANGUAGE_C_PLUS_.PLUS 

#endif 

typedef float Real; 


/* Global variables */ 


const long Factor = 300000L; 

/* Increase this number if your computer is very fast. */ 
long Repetitions, I, J; 
Real Time0, TimeForLoop = 0; 
FILE +f; /+ The log—file. */ 
typedef struct { /+* A typical structure (30 bytes) */ 

int a, 6, c; 

Real d([3]; 

char *e, +f, *9; 

} A-struct; 


Real t:me_since_prog_start( void) 


return (Real) clock() / CLOCKS_PER_SEC; 


void pri(char +izt) 


printf( tzt) ; 
, fprintf(f, txt); 
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void pri2(char *format, char xizt, Real microsec) 


prinif( format, trt, COMPILER, microsec) ; 
fprintf(f, format, ‘tat, COMPILER, microsec) : 


Real ¢(char *str) /* Prints time in microsecs. */ 


Real 10 = 

1e6 * (time_since_prog_start() — TimeO) / Repetitions; 
prt2("%15s410s%6. 2f,microsec\n", str, 10 — TimeForLoop) ; 
return (0; 


void g(void) /* Prepare the test: set globals. «/ 
{ 


Time) = time_since_prog-start( ) ; 
I = Repetitions; J = 0; while (I--) if (++J) ; 
TimeForLoop = 

_ 1e6 * (ttme_since_prog_start() — Time0) / Repetitions; 
I = Repetitions; J = 0; 

Time) = time_since_prog_start( ) ; 


void bytes(void) /* Operations with short ints (bytes) +/ 
{ 


register unsigned char 2, y, z 

Repetitions = 12 * Factor; I] For more accuracy. +/ 
prt( "\noperations, with, byt es:\n"); 

z= 1438; y= 23; 


g(); z= 0; while(/—— > 0) if (444) ate {("inc"); 

g : while I~— > 0) if (4+4+J/) z= c& y; t("log. and") : 
g . while I-— > 0) if (+4+/) z= 2& 7 | y; U("log. yoru") ; 

g - while I-— > 0) if (+4J/) z= 2% y; t("log.yxor"); 
g(); while (J—-— > 0) if (+4+J) z= z>> 1; t("shifty1l"); 
g(); while (J—-— > 0) if (+4+J) z= y/ 2; ("div"): 

g(); while (J—-— > 0) if (44J) z= oy; t("+"); 

g(); while (J—-— > 0) if (4¢4J/) z= xr—y; U("-"); 

g(); while (J—-— > 0) if (+4+J/) z= xe y; t("*"); 

g ; while I-— > 0) if (4+4+J/) z= z/y; ihnaiye) 

a ; while (J—— > 0) if (4+4+J/) z= 2 % y; t('"mod"); 

if (z) ; /* In order to suppress a warning. */ 


} 


void shorts(void) /* Tests operations with shorts (2 bytes) */ 
{ 


register int 2, y, 2; 
Repetttions = 12 * Factor; /* For more accuracy. */ 
pri("\noperations,with,integers:\n''); 
z= 23; y= 103; 
g(); z= 0; while(/-— > 0) if (4+4+J) 244; U("inc"); 
AN while (I-— > 0) if (4+/J) z= r& y; t("log. and"); 


274 Appendix Chapter A. The Programming Package on Your Disk 


9(); while (J-— > 0) if (44+J) z= 2 | y; t("log.yor"); 
g(); while (J—— > 0) if (+4+J) z= 2% y; t("log. uxor") ; 
g(); while (J—— > 0) if (+4+J) z= 2>> 1; t("shifty1"); 
g(); while (I—— > 0) if (+4+J/) z= y/ 2; t(“divy2"); 
g(); while (J-— > 0) if (¢4+J) z= rt y; t("t"); 
g(); while (I—-— > 0) if (44J/) z= z—y; t("-"); 
g(); while (J—— > 0) if (44J/) z= xe y; t("#"); 
g ; while I-— > 0) if (+4+J/) z= z/y;t ihnaay') 
aK ; while (J—-— > 0) if (4+4+J) z= 2% y; t("mody"); 
if (z) ; /* In order to suppress a warning. +/ 


void longs(void) /* Tests operations with long ints (4 bytes) */ 
{ 


register long 2, y, z 

Repetitions = 6 * Factor; /* For more accuracy. */ 
pri("\noperations,with,longint: \n"); 

z= —543210; y = 123456; 

g(); z= 0; while(/—— > 0) if (44J) 244; t("inc"); 

g(); while (I—— > 0) if (¢4+J/) z= 2& y; t("log.yand") ; 
g(); while (I—— > 0) if (44+J) z= | y; t("log.yor"); 

g(); while (J—— > 0) if (+4+J) z= 2% y; t("log.yxor") ; 
g(); while (J—— > 0) if (¢4J) z= «>> 1; t("shifty1"); 
Repetitions /= 10; /* Divisions take a lot of time! 

g(); while (I-- > 0) if (¢4+J) z= y/ 2; t("divy2"); 
Repetitions += 10; 


g(); while (I-— > 0) if (+4+J) z= z+ y; t("+"); 
g(); while (I-— > 0) if (44J) z= 2r— y; t("-"); 
g(); while (J-— > 0) if (+4J) z= 2% y; t("#"); 

















Repetitions /= 10; /* Divisions take a lot of time! */ 

| ; while ‘ie > 0} if(++J) z= az/ y; t("div"); 
g(); while (J—— > 0) if 33 z= tH y; t("mod"); 
if (z) ; /* In order to suppress a warning. +/ 


} 
vers floats(void) /* Tests operations with floats (4 bytes) */ 


register Real z, y, z; 

Repetitions = 3 * Factor; /* For more accuracy. + / 
prt("\noperations,,with floats : \n"); 

z= 1.2432434; y = —562.15; z= 0. 1413; 





g(); while [~~ > 0) if +4J z= orty; tt 

g : while I—-— > 0) if (44J/) z= zr— y; t("-"); 

g : while I~— > 0) if (44 J) z= rx y; t("*"); 

g(); while (J—-— > 0) if (44+J) z= t/y; eat 
Repetitions = 1 * Factor; 

g(); while (J—— > 0) if (++J) z= fabs(z); t("fabs") ; 
g(); while (J~— > 0) if (4++J/) z= sgrt(z); 1 neare"'), 
g(); while (J~— > 0) if (++J) z= sin(z); t("sin"); 

g(); while (J—- > 0) if (¢4¢4+J/) z= cos ; ("cos"); 

g(); while (J—— > 0) if (4+J) z= sin(z)/cos(z); t("“tan") ; 
g(); while (J—— > 0) if (4+J) z= atan(z); t("atan"); 


Section A.5. How Fast Is Your Computer? 275 


g(); while (JI—— > 0) if (++J) z= ezp(z); t("exp"); 


void flf(Real z) { }; 
void f2f(Real z, Real y) { };; 

void f3f(Real z, Real y, Real z) { };; 
void fli(int 1) { };; 

void f2i(int i, int j) { };; 

void f3:(int i, int j, int k) { };; 
void flstp(A-struct *s) 

void flstr( A-struct s) { 


9) 


void function_calls( void ) 


register Real 2 = 1.2345; 
register int y = 1234; 

static A-struct z= { 0 }; 
Repetttions = 10 * Factor; 
pri("\nfunction,calls:\n"); 


g(); while (J—-— > 0) if (++J) flf(z); t("1pReal"); 
g(); while (J—— > 0) if (4+4+J) f2f(2, 2); t("2 Real"); 
g(); while (J—— > 0) if (++J) f8f(z, z, 2); t("3Real") ; 
g(); while (J—— > 0) if (++J) fli(y); t("lushort") ; 
g(); while (J—— > 0) if (4++J) f2i(y, y); t("2ushort") ; 
g(); while (J—— > 0) if (4+4+J) fBi(y, y, y); t("3ushort") ; 
g(); while (J—-— > 0) if (4+4+J) flstp(&z); t("lpaddress") ; 
g(); while (J—— > 0) if (+4+J) flstr(z); t("lustruct") ; 
/* Just for C++: 


Macros are fastest (sometimes together with inline-functions). 
Ordinary function calls take a lot of time. The same is true 
for operators. Even if some people call it "macromania": 

fast C programs still depend heavily on the use of macros! 


*/ 
#ifdef LANGUAGE_C_PLUS_PLUS 
struct V2d { /* A 2d—vector +*/ 
Real z, y; 
V2d() { }; 
vod Rest 20, Real yO) { z= 20; y= y0; } 
friend V2d operator + (V2d &u, V2d &v) 


return V2d(u.z + v.z, uy + v.y); 


}; 

#else 

typedef struct { 
Real z, y; 


w- >t = Uu->z + V-ST; 
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w->y = u- > y + V-—->Y; 


#ifdef _LANGUAGE_C_PLUS_PLUS 
inline void in.sum (V2d &w, V2d &u, V2d &v) 
{ 


W.2= UT + VT; 
wy = Uy t+ V.Y; 


#endif 
#t-define SUM(w, u, v) ((w).c= (u).z + (v).2, (w).y= (u).c + (v)-y) 


void compare_macros_and_functtons( void ) 


V2d a, b, ¢; 
Real the.time[5], min_time; 
az= 1.5; ay => —3.5; b.2= —5.4; by = 7.5; 
Repetitions = 5 * Factor; 
pri("\nmacros,as,opposed,to,function,,calls:\n") ; 
#ifdef _LANGUAGE_C_PLUS_PLUS 
g(); while (J-— > 0) c=a+b,a.2+= 0; 
the_ time[1] = = t("operator"); 
g(); while (J-— > 0) in_sum(c, a, 6), a.xr+= 0; 
the. time [2] = = i("inl.function"); 
#endif 
9(); while (I-— > 0) sum(&c, &a, &), a.z += 0; 
the. time[3] = = t("ord.function"); 
g(); while (I-— > 0) SUM(c, a, 6), a.z += 0; 
the. time [4] = = t("macro"); 
pri("relative result: \n"): ; 
min.time = 1e10; 


#ifdef -LA NGUAGE_C_PLUS-PLUS 


for (; 1 < 5; I++) 
if (min.time > the_time[J]) 
min.time = the_time 

#define PERCENT(1) 100 * the.time[z] / min_time 
#ifdef LANGUAGE_C_PLUS_PLUS 
prt2("%15s%10s%5.0f\%\n", "operator", PERCENT(1)); 
ot "%1584%108%5.0f\%\n", “inl.function", PERCENT(2)); 
#tendif 

prt2("%15s%10s%5.0f\%\n", “ord.function", PERCENT(3) ); 

rote een oes. Of\%\n", "macro", PERCENT(4)); 


FILE +open_logfile( void ) 


f = fopen("speed.log", "w"); 
if (‘f) printf("Cannotopen,logufile! \n"); 
return f; 
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int main() 


if (!open_logfile()) return 1; 

pri "\nPERFORMANCE,,TEST\n") ; 

prt("(The, values, dependon,the,test,numbers!)\n"); 
bytes( ); 

shorts(); 

longs(); 

floats(); 

function_calls() ; 

compare_macros_and_functions() ; 

printf("The,result, hasbeen written,,into,<speed.log>\n") ; 
return 0; 


Finally, we give a table of the results of the program with the following configu- 
rations: 


e A 486/50MHz PC in connection with a Borland C++ compiler, Version 3.1 
(compiler option “fastest code”). 
e A Personal Iris SG35 with a UNIX C compiler (options -float -02). 


e An Indigo2 with a UNIX C compiler (options -float -02). 


This is the result: 


PERFORMANCE TEST 
(The values depend on the test numbers! ) 
Numbers in microseconds 


BC-3.1 SG-35 INDIGO2 
operations with bytes: 


inc 0.08 0.11 0.03 

log. and 0.05 0.09 0.02 
log. or 0.03 0.08 0.02 
log. xor 0.06 0.08 0.02 
shift i 0.05 0.08 0.02 
div 2 0.23 0.09 0.02 

+ 0.03 0.09 0.02 

- 0.08 0.08 0.02 

* 0.05 0.08 0.02 

div 0.06 0.08 0.02 

mod 0.05 0.08 0.02 
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operations with integers: 


inc 0.08 0.08 0.02 
log. and 0.05 0.08 0.02 
log. or 0.02 0.08 0.02 
log. xor 0.06 0.08 0.02 
shift 1 0.03 0.08 0.02 
div 2 0.21 0.08 0.02 
+ 0.08 0.08 0.02 
- 0.05 0.08 0.02 
* 0.03 0.08 0.02 
div 0.05 0.08 0.02 
mod 0.03 0.08 0.02 
operations with longint: 
inc 0.09 0.08 0.02 
log. and 0.12 0.08 0.02 
log. or 0.09 0.08 0.02 
log. xor 0.09 0.08 0.02 
shift 1 0.12 0.08 0.02 
div 2 0.92 0.06 0.02 
+ 0.09 0.08 0.02 
- 0.09 0.08 0.02 
* 0.09 0.47 0.16 
div 0.92 0.11 0.02 
mod 1.22 0.11 0.02 
operations with floats: 
+ 0.37 0.08 0.03 
- 0.31 0.08 0.03 
* 0.31 0.08 0.03 
/ 0.37 0.22 0.17 
fabs 0.37 0.53 0.20 
sqrt 2.93 4.10 2.48 
sin 7.69 2.50 1.85 
cos 7.51 3.47 1.79 
tan 16.67 §.83 3.62 
atan 11.17 4.63 2.86 
exp 15.02 3.43 1.79 
function calls: 
1 Real 0.75 0.41 0.15 
2 Real 0.97 0.46 0.17 
3 Real 1.34 0.52 0.20 
1 short 0.35 0.40 0.15 
2 short 0.33 0.46 0.17 
3 short 0.35 0.52 0.20 
1 address 0.27 0.40 0.16 
1 struct 2.71 1.37 0.68 
Macros as opposed to function calls: 
operator 4.69 0.62 0.22 
inl.function 2.31 0.33 0.13 
ord. function 2.20 0.80 0.45 
macro 1.39 0.31 0.13 
relative result: 
operator 296% 172% 146% 
inl.function 152% 106% 100% 
ord. function 148% 214% 264% 


macro 100% 100% 100% 
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Appendix B 


System Dependencies and Other 
Programming Languages 


How to Change the System-Dependent Commands 


In Chapter 4, we talked about writing programs that are independent of the 
hardware and the compiler that is used. We said that we collect all the system- 
dependent functions in one file named g-functs.c. Additionally, all the system- 
dependent macros are written into one include file named G_macros.h. 


In order to get an idea how such files look like, let us have a look at the two 
files that were developed for an IBM-PC in connection with the WATCOM C 
compiler (Version 10.0) and pick out some examples. 


Example 1: The system-dependent macros 
G_opengraphics(), G_close_graphics(), G_clear_screen() and 
G_swap-_screens() in G_macros.h call functions 
PC_open_graphics(), PC close_graphics(), PCclearscreen() and 
PC_swapbuffers() in g_functs.c: 


#define G_open_graphics() PC_open_graphics( ) 
#define G_close_graphics() PC_close_graphics( ) 
##define G_clear_screen() PC_clearscreen( ) 
#define G_swap_screens() PC_swapbuffers() — 


For the time being these functions may have the following (simplified) 
system-dependent code: 
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void PC_open_graphics ( ) 


_setuideomode (_.VRES256COLOR ); 
/* Standard VGA resolution with 256 colors at the same time. 
May be set to XRES256COLOR (1024 x 768) if your video 
card supports that resolution. +*/ 


} 


void PC-close_graphics () 


-setvideomode (_DEFAULTMODE); 
} 


void PC_clearscreen( ) 


rectangle (_GFILLINTERIOR, 0, 0, 640, 480); 
/+ 640 x 480 is the standard VGA resolution. 
Has to be changed for other resolutions. +/ 


} | 
void PC_swapbuffers( ) 
{ 


-selvisualpage (1 — -getvisualpage ()); 
-setactivepage (1 — _getactivepage ( ))3 


} 


Example 2: The macros G_move() and G_draw() may directly insert the 
system-dependent functions _moveto() and -drawto(): 


#define G_move(v) -—moveto((short) (v)[X], (short) (v)[Y]) 
#tdefine G_draw(v) -drawto((short) (v)[X], (short) (v)[Y]) 


The macros G_area_move(), G_area_draw() and G-area_close() should in- 
sert the functions poly-move(), poly-draw() and poly_close() of Section 4.6. 


Example 3: The macros 
#define G_set_color(a) PC_setcolor((short) a) 
#define G_get_color() PC_getcolor() 
#define G_set_pizel(z, y) PC_setpizel ((short) z, (short) ») 
#define G_get_pizel_color(z, y) PC_getpizel((short) z, (short) y) 


insert calls of the system-dependent functions 
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void PC.setcolor(col) /* For the time being. */ 
short col; 


-setcolor(col); 
int PC_getcolor() /* For the time being. */ 
return _getcolor(); 


void PC_setpizel(z, y) /* For the time being. */ 
short x, y; 


setpizel(z, y); 


short PC_getpizel(z, y) /* For the time being. +/ 
short x, y; 

{ 
return -_getpizel(z, y); 


} 


If it was just the function calls, one should definitely insert the system- 
dependent function calls directly into the macro so as not to waste time 
(see Appendix B.2)! 








One problem with the writing graphics software for PCs, however, is that there 
are so many different video cards on the market. Thus, the above mentioned 
functions will only cover a certain number of video cards. 


The WATCOM C compiler supports standard VGA modes and most of the 
VESA 256 color modes on Super VGA’s (SVGA). The VESA specifications only 
standardize the video mode numbers and the “bits per pixel memory organiza- 
tion” (8 bits per pixel = 1 byte per pixel for 256 colors). So far, however, there 
is no standard for screen pages. Thus, in order to support doublebuffering on 
standardized video cards, we have to write our own graphics primitives. 


The actually implemented code for PC_open_graphics() first tests whether there 
are two screen pages available or not and will use two pages if supported (the 
boolean variable TwoScreens is then set TRUE). 


When we can only use one screen page (this is true for most of the video cards), 
we buffer the whole drawing into a “pseudo screen” in ordinary RAM and not 
into video RAM. When is comes to page flipping, we put the image back on the 
screen. This is a slow solution, but ist works fine for most video cards. (On some 
video cards you have to load a VESA driver before using the program!) 
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The pseudo screen is built up line per line with no additional bytes at the end of 
a line (n pixels per line). Since we need one byte for each pixel, a pixel with the 
coordinates (z, y) has the linear position number (n y+<z) in our pseudo screen. 


There are very fiew basic functions (macros) that actually change the 
pseudo screen: The function PC_setpizel() (PC_set_ror_pizel()), the function 
PC-_clearscreen() and the macro PC_LHORLINE(z1, x2, y) that “draws” a hor- 


izontal line from (x1, y) to (zo, y). 


char CurCol; /* Number of color in color lookup table: 0 < CurCol < 256. */ 
Bool DrawInBack ; 
/* TRUE when TwoScreens = FALSE and not XOR-mode. */ 
typedef struct { 
short rsize, ysize, BitsPerPirel; 
char Data[]; 
/* Huge array that is able to store a screen of the dimensions zsize x 
ysize. Must have the size zsize * ysize. */ 
} PC_image; 
PC_image *Pseudo_screen ; 
/* Has to be allocated in PC_open_graphics( ): 
Pseudo_screen = (PC_image +) malloc(6 + zsize * ysize); 
* 
char +Pseudo_line [768]; 
/* Pseudo_line[k] points to the beginning of the k-th line on the pseudo 
screen: 
for (k= 0; k < ysize; k++) 
Pseudo_line [k] = & Pseudo_screen —> Data[zsize x k]; 
* 
void PC _setcolor(col) /* new version */ 
short col; 


if (Drawln Back ) 
Curcol = col; 

else 
-setcolor(col); 


void PC_setpizel(z, y) /* new version +/ 
short x, y; 


short reg; 
if (DrawlnBack) { 

Region(reg, z, y); 

if (!reg) Pseudo_line[z][y] = CurCol; 
} else 

setpizel(z, y); 


} 


Drawing general lines, filling (convex) polygons, etc., is done by means of the 
routines in Chapter 4. 


Now we redefine the macros G_move() and G_draw();: 
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#-define G_move(v) PC_moveto((short) (v)[X], (short) (v)[Y]) 
define G_draw(v) PC_drawto((short) (v)[X], (short) (v)[Y]) 


They call the functions 


void PC_moveto(z, y) 
short 2, y; 
{ 


if (DrawInBack) { 


CurX = 2; 
CurY = y; 
}else { 


-moveto(z, y); 


} 


void PC_drawto(z, y) 
short z, y; 
{ 


if (DrawInBack ) 
-lineto(z, y); 
else 
plot.ine(CurX, CurY,z, y); 
CurX =2;CurY = y; 
} 
The code of the function PC _swapbuffers() finally looks like this: 


void PC_swapbuffers ( ) 


if (TwoScreens ) { 
_setvisualpage (1 — -getvisualpage( )); 
_setactivepage(1 — -getactivepage( )); 

} else if (DrawInBack) 
-_putimage(0, 0, (char *) Pseudo_screen, -GPSET); 


‘Macromania’: C, ANSI C or C++ ? 
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In this book, the standard C language [KERN86] has been used. It can easily be 


adapted to the ANSI Standard for the C language [DARN88]. 


One major advantage of the ANSI Standard is that the parameters of the function 
calls are checked during the compilation. This makes programming much safer. 
Also, the call of functions will be a little bit faster (the type float, e.g., does not 


have to be converted to the type double). 


The most elegant development of the C language is the C++ language[AT&T90]. 
Actually C++ is a “pseudo language,” since it is based on the C language: 
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as a first step a preprocessor creates a C program that is then compiled by 
the standard C compiler. There is no question that C++ is one of the most 
convenient languages for the writing of readable code. Furthermore, C++ allows 
the protection of variables and the so-called “multiple inheritance.” 


However, C++ has one disadvantage: It will slow down C code like the one you 
can find throughout this book. Here is a typical example: 


Let us redefine the type Vector as a class: 


class Vector { 
float z, y, 2; 
public: 
friend float operator * (Vector v, Vector w) { 
return U.r * W.2 + U.Y*W.Y + UZ ¥ W.Z; 
}; 


}; 
If now a and b are two Vectors and c is a float variable, we can write very 
comfortably 

c=a+ b; 
The C++ preprocessor translates such a line into something like 

c = some_function(&a, &b); 
Since no macro can be used, the C++ version of the dot product of two Vectors 
runs more slowly than the macro version. If you have a C++ compiler at your 


disposal, use the program listed in Appendix A.5 to check how much the loss of 
speed is for your own configuration. It will most probably be more than 50%. 


Thus, if you write a program in C++ and your program runs too slowly, look out 
for segments that are visited frequently and replace the operator by a macro or at 
least by a so-called inline function! (Some people may call this “macromania.” ) 
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B.3 Pointer Arithmetic in PASCAL 


Many high-level programming languages like PASCAL do not support pointer 
arithmetic, because it is tricky and because it can create hard-to-find errors since 
it allows the user to write over non-allocated memory. 


The reason why we make intensive use of pointer arithmetic throughout this 
book is that it speeds up the programs and enables us to write compressed code. 
(Some people call the C language a “veiled assembler.” ) 


If you prefer to write PASCAL programs while still using code listed in this book 
you can do this by using a unit pointers. The unit contains the functions pp 
and mm/() corresponding to ++, += and —-—, —= anda function smalle 
which compares two addresses. 


Here is the listing of such a unit for an IBM-PC and with “Turbo-PAS(C 
Since the functions are not optimized, they will not run as fast as an o7 
PASCAL code. If they are implemented as assembler routines, they wi 
up the code. 


[a 
unit pointers; 
interface 
type 
ptr = record 
offs, segm: word; 
end; 
procedure pp(var p; s: integer); 
procedure mm(var p; s: integer); 
function smaller(var pl, p2): boolean; 
implementation 
procedure pp(var p; s: integer); 
begin inc(ptr(p).offs, s) end; 
procedure mm(var p; s: integer); 
begin dec(ptr(p).of fs, s) end; 
function smaller(var pl, p2): boolean; 
var sl, s2: word; 
begin 
sl := seg(pl); s2 := seg(p2); 
if sl = s2 then smaller := (ofs(pl) < ofs(p2)) 
else smaller := (sl < s2); 
end; 


end. (+ unit pointers *) 
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To give you an idea of how this unit can be used, we list a sample program. 
First the listing of the C file: 


as 
#define X 0 

#define Y 1 

#define Z 2 

#define N1 30 

#define N2 20 

typedef float Vec3 (3]; 

typedef float Vec2 [2]; 

Vec3 v3[N1][N2], *p3; 

Vec2 v2[N1][N2], *p2, *p-array[N1], * * pptr; 
float *«r, *hi_r; 

int i, j, k; 

void main() 


/* Example 1: Initialize array with zeros. */ 
/* First the ordinary C code. */ 
for (t= 0; i< N1; i++) 

for (j = 0; 7 < N2; j++) 

v3[a[X] = 3[] bY] = [J U]lZ] = 0; 

/* Now the same with pointer arithmetic. +/ 
r= (float *) v3; 
hir = r+ 3 *N1 *N2; 
while (r <_ hi_r) 

r++ = 0; 
/x Example 2: Copy arrays of different types. */ 
/* First the ‘readable’ code. x/ 
for (i = 0; 7< N1; i++) 

for (j = 0; 7 < N2; j++) { 
v2la [LX] = v3fdbI[X]; 
2(|Y] = 3[DI[Y]; 


/+ Now the same with pointer arithmetic. «/ 

p2 = (Vec2 *) v2; 

ps = (Vec3 *) v3; 

for (t = 0; i< (NI *N2); i++) { 
(*p2)[X] = (+p3)[X]; (*p2)[Y] = (*p3)[Y]; 
p2++; p3++; 


/* Example 3: How to use pointers to pointers. */ 
pptr = p_array; 
for (¢ = 0; «< N1; i++) 
+ pptr++ = v2[i); 
pptr = &p-array[N1 — 1]; 
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= 0; i< NI1; i++) { 
p2 = *pptr——; 
} = 0; j < N2; j++) { 


This is the one-to-one translation into PASCAL: 


| 
program pointer test; 
(« This sample program shows how to use the unit 
pointers. * ) 


uses pointers; 


const 
X=0;Y = 1,52 = 2; 
N1 = 30; N2 = 20; 
type 


Vec3 = array[X..Z] of real; 
Vec_ptr3 = °Vec3; 
Vec2 = array[X..Y] of real; 
Vec_ptr2 = ~ Vec2; 
Real_ptr = “real; 
ppt = “pointer; 
var 
v3: array(0..N1 —1, 0..N2—1] of Vec3; 
v2: array(0..N1 —1, 0..N2—- 1] of Vec2; 
p3: Vec_ptr3; 
p2: Vec_ptr2; 
r, hir: Real_ptr; 
pptr: ppt; 
p-array: array[(0..N1 — 1] of Vec_ptr2; 
i,j,k: integer; 
zeros: Vec3; 
(#*** MAIN * &* ) 
begin 
(* Example 1: Initialize array with zeros. *) 
(* First the ordinary Pascal code. *) 
zero3[X] := 0; zero3[Y] := 0; zero3[Z] := 0; 
for 1:= 0 to NI —1do 
for j :=0 to N2-1do 
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v3[i, j] := zero3;' 
(* Now the same with pointer arithmetic. *) 
r:= @v3; 
hir := r; pp(hir, 3 *N1 *N2 *sizeof(r’)); 
while smaller(r’, hi-r>) do begin 
r° := 0; pp(r, sizeof(r*)); 
end; 
(* Example 2: Copy arrays of different type. +) 
(* First the ‘readable’ code. *) 
for i:= 0 to N1-—1do 
for j := 0 to N2—-1 do begin 
v2[t,9,X] := v3lt, 7, X); 
vi, iY] = 0965,5,Y) 
end; 
(* Now the same with pointer arithmetic: +) 
p2 := @v2; 
p3 := @Qv3; 
for i:= 0 to NI *N2 — 1 do begin 
p2°-[X] := p3°[X]; p2°[Y] := p3°[Y]; 
pp(p2, sizeof(p2°)); pp(p3, sizeof(p3°)); 
end; 
(* Example 3: How to use pointers to pointers. +) 
pptr := @p-_array/(0); 
for 7:= 0 to NI —1 do begin 
pptr®> := @v2li); 
pp(pptr, sizeof(pptr)); 
end; 
pptr := @p-array[N1 — 1); 
for 1:= 0 to N1 -—1 do begin 
p2 := pptr’; mm(pptr, sizeof(pptr’ )); 
for j := 0 to N2-1 do begin 
p2°[X] := 0; p2°[Y] := 0; 
pp(p2, sizeof(p2°)); 
end; 
end; 
end 


Ce 


‘zero$ is an array of real. This would not work in C! 
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ABOVE (macro), 44 
accelerating a program, 58 
acceleration of a program, 283 
active palettes, 256 
Add_vec (macro), 18 
address 

size of, 16 

constant, 117 

of a structure, 8 

of a variable, 12, 58 

of a float, 8 

of an array, 16, 151 
AKIMA, 234 
AKIMA (macro), 235 
Akima splines, 240 


akima_spline_curve (function), 


akima_tangents() (function), 236 


algebraic curve, 235 
algebraic function, 210 


algebraic surface, 211, 212, 226 


Alloc_2d_array (macro), 65 
Alloc_array (macro), 62 
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Alloc_huge.2d_array (macro), 
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Alloc_ptr_array (macro), 62 
Alloc_string (macro), 86 
allocation 
of higher dimensional ar- 
rays, 65 
of memory, 58 
AMBIENT (macro), 115 
ambiguity in the priority test, 
151 


angle 


between a plane and a straight 


line, 11 
between lines, 1 
of elevation, 251, 253 
of incidence, 10, 173, 183, 
226, 228, 229 
average, 10, 111 
of inclination, 249 
of reflection, 229 
ANIM, 268 
anim.zp, 268 
animation, 96, 150, 255 
animation file, 268, 271 
ANSI C, 3, 258, 280, 283 
applied sciences, 133 
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approximating polyhedron, 213, 
249 
approximating spline surfaces, 


approximating splines, 242, 246 
approximation of surfaces, 249 
approximations to surfaces of 
revolution, 129 

Area_of.2d_triangle (macro), 158 
argument list, 12 
array 

allocation, 65 

free, 66 

initialization, 4 

more-dimensional, 60 

of float variables, 20 

of pointers, 60 

of float variables, 5, 8 

of Vectors, 58 

of Vectors, 49 

twodimensional, 65 
ASCII-file, 267 
assembler, 284 
aura, 190 
average normals, 213 
average_dist() (function), 143 
average_normals() (function), 

217 


Average_z (global variable), 115 
axis of the polyhedron, 131 
azimuth angle, 38 

Aztec C' compiler 3.0, 268 


B-splines, 240, 243 
B_SPLINE (macro), 240 
b_spline_coeff() (function), 244 
b_spline_curve (function), 245 
back objects, 144 
backbuffer, 96 
Backface (macro), 115 
backface removal, 194 
backfaces, 82, 127, 192, 193 
BACKGROUND (macro), 104 
background color, 183 
background light, 111 
Backlit (macro), 115 
backslash, 271 
barycenter 

of a face, 111 





of a polygon, 10 
of an object, 136 

base points, 82 

base polygon, 82 

base rectangle, 213 

BEHIND (macro), 46 

BELOW (macro), 44 

G-splines, 242 

Between_zero.and_one (macro), 
164 

Bezier-splines, 242 

binary file, 258 

bit planes, 99, 100, 102 

bits per pixel, 97 

bitwise operations, 43 

Bool (type definition), 11 

Borland C++ compiler, 277 

bottleneck, 80, 272 

bouncing reflections, 177 

bounding box, 140 

bounding rectangles, 135, 150, 
187 

bounding_boa() (function), 151 

bounds-checking, 16 

BOX (macro), 82 

box, 82, 231 

branch of a curve, 213, 250 

breakpoint, 243 

Bresenham Algorithm, 117 

brightness of a face, 110 

brightness of a polygon, 10 

buffer_line() (function), 261 

buffer_polygon() (function), 262 

buffer_scene() (function), 199 

Buffered_plane (global variable), 
197 


C preprocessor, 60, 102 

C’ continuity, 233, 234 

C? continuity, 237 

calc_rot_matriaz() (function), 39 

calc_shade_of_face() (function), 
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(xcalc_spline_curve)() (function 
pointer), 240 

calc_spline_surface (function), 
241 

calculation time, 213, 250 

call by reference, 12 


call by value, 12 

camera lens, 25 

Cartesian coordinate system, 
1, 213 

cast shadow, 127, 140, 155, 
175, 176, 180 

check_keyword() (function), 70 

circle in 3-space, 202 

C* continuity, 243, 247 

class, 283 

classes of curves, 213 

clear screen, 96 

clear_z_buffer() (function), 197 

clip volume, 197 

clip2d_line() (function), 44 

clip2d_polygon() (function), 49 

clip8d_line() (function), 48 

clip3d_polygon() (function), 53 

clip_and_draw_polygon() (func- 
tion), 52 

clip_and_plot_line() (function), 
46 


clip_conves (function), 169 
(«clip_line)() (function pointer), 
45 


(x clip_polygon)() (function pointer), 
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Clip_reg (global variable), 46 
Clip_vol (global variable), 45 
clipping routines, 43 

clipping volume, 47 

close screen, 96 
close_together() (function), 91 
CODE, 267 

coefficient vectors, 234 
coefficients, 243 
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color entries, 102 

color lookup-table, 97 

color maps, 97 

color of the background, 185 
color palettes, 95, 258 
color_indez() (function), 103 
colored light sources, 230 
colorless face, 183 

command line, 258 

Comment (global variable), 70 
Commodore Amiga, 268 
common_edge() (function), 73 
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compatability, 256 

compilation, 117 

compiler, 10, 96, 268, 271, 272, 
279 

complicated object lists, 85 

compressed code, 284 

computation time, 177, 194, 
196, 271 

computer-generated movie, 255 

concat.to_polygons (function), 
157 

concatenated curve, 233 

concave polygon, 68 

conditional branchings, 46, 53 

cone, 211 

configuration, 271 

consistency of a surface, 229 

constant of a plane, 8 

construction of roads, 253 

contour condition, 224 

contour line, 201, 224, 247 

contour point, 224 

contour polygon, 156, 248 

contour_condition() (function), 
224 

contradiction in the priority 
list, 137 

control points, 235, 242, 244 

CONVEX (macro), 76 

convex, 85 

convex outline, 128, 187, 193 

convex polygon, vi, 68 

convex polyhedron, 127, 186, 
194 

« Coord_pool (global variable), 
37 

coordinate box, 152 

coordinates, 1 

Copy_vec (macro), 48 

Copy_vec2 (macro), 48 

corr_ptr() (function), 92 

corr_vertez() (function), 76 

C++ language, 283 

C++ preprocessor, 283 

CPU, 213 

create_coord_box() (function), 
152 

create_palettes() (function), 102 
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critical objects, 143 

Cross.product (macro), 7 

cubic parabola, 215, 219, 233 

cubic splines, 230, 237, 238, 
240 

cubic_parabola() (function), 216 

CUBIC_SPLINE (macro), 240 

cubic_spline_curve (function), 
238 

Cur-_color (global variable), 97 

+ Cur_coord (global variable), 
60 

+ Cur_edge (global variable), 
61 


« Cur_face (global variable), 61 

« Cur_object (global variable), 
61 

Cur-_palette (global variable), 
261 

Cur-poly_color (global variable), 
261 


Cur-shade (global variable), 116, 
261 

curves on a surface, 201, 205 

cut_face_with_plane() (function), 
90 

cut_line() (function), 219 

cyclid, 212 

cylinder, 211 


dark faces, 111 
DATA, 268, 270 
data file, 85, 268, 271 
data pools, 65 
data.zp, 268 
dead end, 150 
declaration of variables, 18 
default directory, 271 
degree | 
of a coefficient, 243 
of an algebraic curve, 235 
of an algebraic surface, 
211, 212 
of freedom, 247 
depth buffering, 195, 231 
description of geometrical ob- 
jects, 57 
Desk Top, 102 
deviation, 249 





deviation() (function), 221 

deviation angle, 221 

device coordinates, 32 

difference of two vectors, 2 

different kinds of computers, 
95 

differential equation, 249, 254 

differential form, 202 

Dim (global variable), 49 

direction fields, 251 

direction vector, 202 

directory, 271 

DISJOINT (macro), 141 

disk space, 256 

disk-device, 269 

diskette, 267 

(xdisplay_scene)() (function pointer) 
109 


distance between two points, 


9 
divide_points (function), 162 
division by zero, 12 
domain of definition, 134, 250 
DOS environment, 259, 267, 
| 269 
dot product, 6, 7, 10, 224, 283 
Dot.product (macro), 7 
Dot.product2 (macro), 13 
double, 5 
double buffering, 96, 99, 100 
double-buffer mode, 96 
double precision, 5 
draw_buffered_line() (function), 
199 
draw_depthcued_wireframe() (func- 
tion), 108 
(«draw_line)() (function pointer), 
46 


(xdraw_polygon)() (function pointer). 
52 
(*draw_scan)() (function pointer), 
196 
draw-wireframe() (function), 
105 


drawing order for the slices, 
134 

drawing plane, 43 

Dupin’s cyclid, 212 


Edge (type definition), 88 

edge list, 86, 192 

edge_in_plane() (function), 92 

** E;dge_pool (global variable), 
61 


eight bit integers, 256 
elevation angle, 38 
ellipsoid, 211 
Email-address, 267 
END_MOVIE (macro), 256 
Enlarge (global variable), 40 
EOF flag, 259 
EPS (macro), 9 
EPS1 (macro), 151 
equation 

of a plane, 8 

of a straight line, 2 
equipotential lines, 254 
ESCAPE (macro), 109 
executable file, 269 
extract numbers from a 

compressed file, 260 

eye point, 271 


(«f_z)() (function pointer), 216 
Face (type definition), 66 
face list, 86 

+ Face_pool (global variable), 61 
face.types() (function), 128 
FALSE (macro), 11 

families of curves, 250 

family of surfaces, 209 

FAST3D, 268 

field value, 195 

file header, 256 

fill algorithm for polygons, 119 
fill.color_pool() (function), 107 
fill_light_pool() (function), 64 
fill_poly() (function), 98 
fill_rot-matriz() (function), 38 
fill_screen_pool() (function), 63 
fill_trapezoid() (function), 122 
filling of convex polygons, 96 
film camera, 255 

first derivation, 234 

float, 5 

Float.to_Ushort (macro), 197 
floating horizon algorithm, 134 
floodfill, 119 
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flush buffer, 263 

flush_poly() (function), 121 

focal distances, 31 

forbidden halfspace, 30, 35, 53, 
64 

forbidden points, 30, 43 

framebuffer, 96 

Fread_str (macro), 70 

Fread_vec (macro), 70 

Free_2d_array (macro), 66 

freeze a movie, 256 

front objects, 143 

frontbuffer, 96 

frontfaces, 82, 127, 186, 193 

full RGB mode, 97 

Full_width (global variable), 115 

function argument, 16 

function graph, 133, 176, 185, 
213, 222, 233, 249, 
253, 254 

function headers, 3 

function prototypes, vi 

fundamental condition for the 
use of the painter’s 
algorithm, 136 


G_beep (system-dependent macro), 
97 
G_clear_screen (system-dependent 
macro), 96 
G_clear_screen() (function), 280 
G_close_area (system-dependent 
macro), 97 
G_close_graphics (system-dependent 
macro), 96 
G_close_graphics() (function), 
280 
G_colors_for_depth_cuing (system- 
dependent macro), 107 
G_create.RGB_color (system- 
dependent macro), 96 
G_create.RGB_color() (function), 
281 
G_depth_cuing (system-dependent 
macro), 107 
G_depths_for_depth_cuing (system- 
dependent macro), 107 
G_double_buffer() (function), 
281 
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G_draw (system-dependent macro), 
97 

G_draw-area (system-dependent 
macro), 97 

G_draw_zy (system-dependent 
macro), 97 

g-functs.c, 95, 267, 269, 279, 
280 

g-functs.o, 95 

G_get_pizel_color (system-dependent 
macro), 97 

G_key_pressed (system-dependent 
macro), 97 

G.macros.h, 4, 95, 101, 102, 
267, 269, 279 

G_move (system-dependent macro), 
97 

G_move_area (system-dependent 
macro), 97 

G_move_szy (system-dependent 
macro), 97 

G_open_graphics (system-dependent 
macro), 96 

G_open_graphics() (function), 
280 

G_set_color (system-dependent 
macro), 97 

G_set_pizel (system-dependent 
macro), 97 

G_swap_screens (system-dependent 
macro), 96 

G_swap_screens() (function), 281 

gears .vdi, 268 

gears .vd2, 268 

general object lists, 85 

generalized helices, 251 

generating a surface, 205 

generating line, 205, 207, 209 

geometrical primitives, 74 

get_edges_from_facelist() 
(function), 73 

Global (macro), 4 

global, 260 

global variable, 117 

global variables, vi, 3 

Globals.h, 3, 4 

Gordian knot, 137, 143, 144, 
150 

goto, 141 


Gouraud shading, 111, 119, 123 
graphics computer, 96, 255 
graphics hardware, 95, 255 
graphics mode, 96 

graphics monitor, 96 
graphics object editor, 57 
graphics output, 98 
graphics workstations, 255 
grid, 240 

grid dimensions, 195 

grid over the screen, 195 
grid points, 218 

groups are disjoint, 150 


Half.width (global variable), 
115 

Halfspace (type definition), 
139 


halfspace, 35, 177 
hard copies, 185 
hardware, 95, 271 
hardware depth cuing, 106 
hardware-clipping, 43 
HARDWARE_DEPTH_CUING 
(macro), 107 
helical motion, 207, 208 
helical surface, 207 
helicoid, 207 
helix, 202, 251 
hidden zones, 187, 190, 193 
hidden-line algorithm, 194 
general, 199 
screen-oriented, 185, 194 
space-oriented, 185 
hidden-line removal, 186 
hidden-surface algorithms, 253 
high-level programming lan- 
guages, 141, 284 
higher-dimensional arrays, 65 
highlighted point, 229 
highlighted spot, 112, 228, 230 
HLS system (Hue, Lightness, 
Saturation), 100 
Hodgman-Sutherland algorithm, 
49 


hole, 193 

HOLLOW (macro), 76 
horizontal zones, 196 
hue, 99 


hues of a color, 99 
hull() (function), 161 
hyperboloid, 211, 226 


identical() (function), 217 

IFF-standard, 256 

illuminated spots, 183 

image plane, 183, 195 

image polygon, 183 

imaginary object, 177 

implicit equation, 11, 184, 210, 
211, 226 

implicit surfaces, 247 

Impuls, 268 

#include, 3 

include file, 3, 95, 279 

indices of the objects, 143 

Indigo, 267 

Indigo2, 277 

INFINITE (macro), 11 

infinite line, 208 

infinite point, 234 

INFRONT (macro), 46 

Init (macro), 4 

Init_fptr (macro), 4 

init_video_buffer() (function), 
261 

initialization, 5, 45, 47, 197 

inline function, 283 

«Input (global variable), 70 

inside_poly (function), 166 

install, 269 

integral curves, 212, 251 

integral polygon, 252 

Intensity (global variable), 115 

interpolating cubic splines, 229, 
238 

interpolating curves, 233 

interpolating spline, 234 

interpolating spline curves, 240 

interpolating surface, 233 

intersect_lines() (function), 13 

intersect_objects() (function), 
88 

intersect_segments() (function), 
15 

intersecting polyhedra, 85 

INTERSECTION (macro), 141 

intersection of surfaces, 201 
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intersection of the outlines of 
two polyhedra, 137 

intersection of two cylinders, 
204 

intersection point, 11, 187 

intersection polygons, 183 

intpol() (function), 47 

inverse_rot_matriz() (function), 
39 

inversion, 212 

inversion of the refraction, 183 

invisible.zones() (function), 187 

InvRot (global variable), 38 

Tris 3020, 267 

Is_convex (macro), 76 

Is_large.enough (macro), 164 

is_on_azis() (function), 75 

Is_zero (macro), 11 

isophotes, 226, 249 


K&R standard, 3, 279 
Kernigham/Ritchie, 3 
keyword, 12, 70, 76, 271 
knot, 233, 243 


Lambert’s cosine law, 10, 111 

landscape, 201, 253 

landslide, 253 

laser printer, 126, 186 

law of reflection, 229 

LEFT (macro), 43 

Length (macro), 9 

library functions, 272 

light ray, 226 

light systems, 35, 43, 63, 140, 
173, 231 

Light_coords (macro), 63 

*Light_pool (global variable), 
60 


light_to_world() (function), 43 

line drawings, 185 

line element, 234 

line of intersection, 203, 213, 
226, 249 

line segments, 213 

linear combination, 2, 8, 251 

linear transformation, 194 

Linear_comb (macro), 11 

Linear_comb2 (macro), 13 
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lines of equal illumination, 249 

lines of intersection, 249 

locally visible, 186 

lookup-tables for RGB colors, 
230 

loxodrome on a sphere, 203 

loxodromes, 250 


macromania, 283 

macros, vi, 3 

Macros.h, 3 

MAIN, 100 

MAIN (macro), 4 

main.c, 3 

make.spectrum() (function), 100 

makefile, 266, 267 

malloc(long), 59 

manipulate_scene() (function), 
109 


* Map-color (global variable), 
102 
material, 229 
mathematical curve, 202 
mathematical formulas, 202 
mathematical surface, 205 
mathematics coprocessor, 10 
matriz_mult() (function), 22 
MAX._12_BIT (macro), 256 
Maz-depth (global variable), 
107 
MAX_EDGES (macro), 60 
MAX_FACES (macro), 60 
MAX_LIGHTS (macro), 37 
MAX_PAL (macro), 102 
MAX_POINTS (macro), 60 
MAX_POL (macro), 60 
MAX_SYST (macro), 37 
MAX_UBYTE (macro), 60 
Maz-z (global variable), 43 
Maz-_z-_grid (global variable), 
196 
Maz-y (global variable), 43 
Maz-y-_grid (global variable), 
196 


Maz.z (global variable), 46 

Maszimum (macro), 86 

measured data, 230, 247 

measuring of angles in space, 
10 


Megabytes, 194, 195 

mem_alloc() (function), 59 

mem_realloc() (function), 59 

memory, 196 

memory allocation, 196 

memory allocation failings, 58 

meridian circles, 203 

meridian line, 206 

meridian plane, 74 

meridian polygon, 74 

Microsoft C compiler, 268 

mikado algorithm, 143, 144 

mikado-select (function), 147 

Min_depth (global variable), 107 

Min_maz (macro), 151 

Min_maz-vec (macro), 151 

min_maz_vec_of_pool() (func- 
tion), 151 

Min_z (global variable), 43 

Min_y (global variable), 43 

Min_z (global variable), 46 

minimal radius, 136 

Minimum (macro), 86 

minimum and maximum 
coordinates, 151 

mirror plane, 177 

mirrors, 177 

mixed colors, 230 

module, 47, 216, 260 

mouse, 57 

move_buffer() (function), 198 

(«move_scan)() (function pointer), 
196 

movie previewer, 255, 266 

MS-DOS, 267 

multi-tasking, 96 

multiple inheritance, 283 

must_be.keyword() (function), 
77 


necessary_to_plot() (function), 
264 


neighboring faces, 248 

neighboring slices, 131 

neighboring spans, 233 

neighboring triangles, 213 

NEW_FRAME (macro), 256 

New-_image (global variable), 
263 


NEWTON’s iteration, 184, 215, 
219 

NO-_COLOR (macro), 80 

No-of_lights (global variable), 
37 

non-allocated memory, 284 

non-solid, 128 

NONE (macro), 140 

normal vector, 8 

Normal_vec2 (macro), 13 

normal.vector() (function), 86 

normalize_vec() (function), 9 

normalized device coordinates, 
32 

normalized direction, 202, 229 

normalized normal vector, 229 

NOT_FOUND (macro), 140 

NULL (macro), 59 

number of bit planes, 97 


object file, 96 

object group, 150 

object preprocessor, 57, 177 

« Object_pool (global variable), 
61 


obscured face, 183 

one-eyed seeing, 25 

one-to-one correlation, 213 

open screen, 96 

optimized normals, 221, 222 

optimized triangulation, 221, 
222 

order, 20, 74-76, 78, 80, 1285, 
127, 129, 131, 133, 
134, 143, 158, 169, 
175, 177, 192, 199 

orient_ptr_poly() (function), 158 

oriented normal, 248 

origin, 1 

orthogonal projection, 202 

OS/2, 269 

oscillation, 235, 238 

out of memory error, 196 

outline, 156, 186, 192 

+ Output (global variable), 58 

overlap() (function), 142 


P_ptr (type definition), 160 
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pack_or_-unpack_96_bits() (func- 
tion), 257 

page flipping, 96, 99, 100 

painter’s algorithm, 125-127, 
136, 155, 177, 182, 
185 

pairwise orthogonal axes, 1 

Palette (type definition), 100 

parabola, 215 

parabola segments, 233 

paraboloid, 211 

Parallel_z (macro), 13 

parallelepiped, 82 

parameter, 3 

parameter check, 283 

parameter interval, 243 

parameter lines, 248 

parametric equation, 11, 243 

parametric representation, 204, 
205 

parametrized curves, 204, 249 

parametrized equation, 205, 233 

parent palettes, 99 

Parent_palette (global variable), 
100 


parts of the graphs, 134 

PASCAL, 8, 12, 284 

pass by reference, 8 

pass by value, 8 

patch, 240 

patterns, 57, 185, 186 

PC, 277, 279, 284 

pencil of planes, 131 

perfect images, 190 

Personal Iris SG35, 277 

Phong shading, 99, 228 

photographs from the screen, 
185 

physical device coordinates, 32 

PI (macro), 39 

Pixel (type definition), 282 

pixel, 183, 195 

Pizel_ratio (global variable), 
40 


pixels, 96 

plain shading, 261 

planar polygon, 68 

Plane (type definition), 8 
plane, 8 
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plane_constants() (function), 
8 


plot_convez_polyhedron() (func- 
tion), 128 
plot_line() (function), 117 


plot_polyhedron_with_convez_outline() 


(function), 129 
plot_visible_zones() (function), 
190 


plotter drawings, 126, 186, 201, 
248 


Point_on_line (macro), 6 


- point_on_line() (function), 5 


Point_region (macro), 48 

pointer arithmetic, vi, 1, 7, 
214, 284 

pointer to a function, 46, 53 

pointer to a float, 10 

pointer variables, 12 

pointers.pas (PASCAL unit), 
284 

pointers into pools, 61 

pointers to functions, 5 

pointers to the vertices, 86 

POLY1_INSIDE_POLY2 (macro), 
141 

POLY2_INSIDE_POLY1 (macro), 
141 

Poly2d (type definition), 260 

poly_close() (function), 120 

poly_draw() (function), 120 

poly_move() (function), 120 

polygonization, 247 

Polyhedron (type definition), 
68 

pools, 65 

position vector, 1, 2, 250 

PostScript, vi 

PostScript, 126 

Postscript, 185 

potential area, 254 

precision, 5 

prefix, 61 

prerequisite for the painter’s 
algorithm, 150 

previewer, 255 

principal point, 34 

printer, 186 

printing techniques, 183 


priorities() (function), 145 

priorities among the ribbons, 
131 

priority algorithm, 125 

priority list, 144, 186, 187 

priority lists of several objects, 
135 

priority test, 135 

Proj_center (global variable), 
37 


projection center, 29, 177 
projection ray, 224, 229 
proportional scaling, 209 
Proto.h, 3, 5 
pseudo language, 283 
pseudo-code, 57, 86, 145, 214, 
250, 252, 266 
ptr_to_calc_spline() (function), 
240 


ptr_to_section() (function), 220 

ptr_to_verter() (function), 91 

publications, 185 

put_or_get_96_bits() (function), 
207 


quadratic equation, 251 

quadrics, 211 

quadrilaterals, 258 

quick_draw_buffer() (function), 
198 

quick_line() (function), 98 


radiosity method, 155, 172 

rain water, 253 

RAM, 196, 199 

range errors, 58 

ray tracing, 155, 177, 180, 182 

read.me, 267 

read_convez_obj_of_rev() (func- 
tion), 77 

read_convez_obj_of_transl() (func- 
tion), 82 

read_float() (function), 77 

read_general_convex_polyhedron() 
(function), 71 

read_pos_int() (function), 72 

readable data, 85 

real time, vi, 43, 255, 271 

Realloc (macro), 62 


Realloc_ptr_array (macro), 62 

reallocation of memory, 58, 60, 
62 

receive_12_bit_int() (function), 
260 


record a movie, 255 

rectangular domain, 250 

recursive, 143 

REDUCED_PAL (macro), 115 

reentrant polygon clipping, 49 

reflected light ray, 229 

reflecting elements, 177 

reflecting faces, 177 

reflecting surfaces, 57 

reflection ray, 229 

reflections, 177 

reflections on curved surfaces, 
177 

refraction, 183 

Reg (global variable), 46 

Region (macro), 44 

Region3d (macro), 46 

regions, 43 

register variables, 18 

relative positions, 150 

relative_pos_of_hulls (function), 
164 

release_buffer() (function), 263 

removal of hidden lines, 185 

rendering of the scene, 148 

replay, 269 

replay a video file, 43, 255 

replay.c, 266 

replay.exe, 269 

residual objects, 144 

RGB colors, 230 

RGB mode, 97 

RGB value, 97, 99 

RGB vector, 99 

RGB-values, vi 

ribbons, 143 

RIGHT (macro), 44 

Rot (global variable), 38 

Rot_matrix (type definition), 
21 

Rotate_and_illuminate (macro), 
41 

Rotate_and_project (macro), 41 

rotation angle, 74 
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rotational sweeping, 74 
rotoid, 202 

rotoidal motion, 208 
rotoidal surfaces, 208 
Round_vec (macro), 100 
rubber band, 43, 117 
ruled surfaces, 202, 207 


safe_ezit() (function), 58 

safe_open() (function), 70 

Scale_factor (global variable), 
40 


Scale_vec (macro), 100 

scaling nature of pointers, 19, 
62 

scan-line algorithms, 196 

screen resolution, 96, 183, 186, 
190, 195, 255 


screen system, 26, 34, 35, 43, 


63, 106, 114, 119, 140, 
231 
Screen_coords (macro), 63 
«Screen_pool (global variable), 
60 
SCREEN_SYST (macro), 37 
Screen_to_light (macro), 156 
screen.to_world() (function), 41 
sect_line_and_plane() (function), 
11 
sect_polys() (function), 16 
sector, 131 
segment_cuts_poly() (function), 
188 


segments, 213 

self-intersections, 228 

Send_12_bit_int (macro), 259 

send_12_bit_int() (function), 259 

Send_8_bit_int (macro), 259 

sep_plane_between_obj() (func- 
tion), 153 

separating plane, 153 

set of points, 210, 235 

Set3 (macro), 80 

Set4 (macro), 80 

set_ft) (function), 81 

Set_map_color (macro), 104 

set_plane_point() (function), 197 

Set_xor_pizel (macro), 118 

SG-35, 267 
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sg.zp, 267 

shade, 67, 95, 99, 108, 123, 
230, 231 

shade() (function), 116 

Shade_of_verter (global vari- 
able), 116 


shade_scan_line() (function), 123 


shades of a color, 99 

Shades_of.vertices (global vari- 
able), 261 

shading model, 182, 185, 228 

shadow buffering, 232 

shadow polygon, 183, 231 

sharp bend, 234, 244 

sides of a plane, 8 

Sign (macro), 16 

Silicon Graphics environment, 
267 

Silicon Graphics Library, 267 

Silicon Graphics Workstation, 
267, 269 

single precision, 5 

size of the array, 16 

skew, 208 

slash, 271 

slope, 250 

smooth curve, 234 

smooth reflecting surfaces, 228 

smooth shapes, 246 

smooth-shaded polygon, 261 

smooth-shaded surface, 258 

Smooth_shading (global vari- 
able), 115 

soap bubble, 136, 153 

soap bubble test, 136 

software errors, 58 

Solid (global variable), 115 


sort_and_render_objects() (func- 


tion), 148 
sort_objects (function), 146 
sorting is not possible, 147 
sorting time, 149 
source code, vi, 267 
source.zp, 267 
space coordinates, 5 
span, 233, 243 
spatial geometry, 1 
spatial integral curves, 249 
spatial_hull() (function), 156 


speed, 269, 271 
speed of a graphics program, 
6, 37, 49, 95, 114, 135, 


150, 153, 186 
speed.c, 272 
sphere, 136 


spherical coordinates, 38 
spherical_coords() (function), 
38 


spiral, 202 
spiral surfaces, 209 
spline curve, 233 
spline surfaces, 201 
standard C language, 259, 283 
starting position of the prim- 
itives, 133 
statement labels, 141 
STATIC (macro), 169 
steepest slope, 251 
storage limits, 58 
store drawings, 43 
store the screen pixel by pixel, 
255 
Store_coords (macro), 77 
Store_image (global variable), 
208 
straight line, 202, 211 
Subt_vec (macro), 8 
Subt_vec2 (macro), 13 
surface material, 229 
surface normal, 229 
surfaces 
algebraic, 211 
of revolution, 206, 230 
of translation, 82, 205 
ruled, 207 
spiral, 209 
Swap (macro), 16 
swap screens, 263 
Switch_syst (macro), 63 
SYSTDEPS, 267 
system calls, 272 
system independence, 256 
system-dependent functions, 279 
system-dependent macros, 279 
system-dependent module, 95, 
267 


T2 (macro), 107 


tangent plane, 250 
tangent vector, 224, 234, 250 
Target (global variable), 37 
tc_close_area() (function), 282 
tc_draw-_area() (function), 282 
tc_move_area() (function), 282 
technical drawings, 185 
terrain, 247, 253 
text editor, 57 
three-dimensional objects, 25 
tolerance, 195 
torus, 211, 212, 226, 249 
Total_depth (global variable), 
107 


Total_edges (global variable), 
62 

Total_faces (global variable), 
62 


Total_objects (global variable), 
62 

Total_systems (global variable), 
37 


Total_vertices (global variable), 
37 
trajectories, 252, 254 
transcendent equation, 184 
translate_pool() (function), 18 
translate_world_system() (func- 
tion), 37 
TRANSLATION (macro), 82 
translation surface, 205 
translation vector, 82 
translational sweeping, 82 
transparency, 57, 119 
transparent face, 183 
transparent material, 183 
transparent plane surfaces, 182 
transparent solid polyhedra, 
182 
Triangle (type definition), 219 
triangulate_surface (function), 
221 
triangulation, 213, 221, 222, 
247 
trigonometric functions, 10 
trivial edge list, 86 
trivial_edge_list() (function), 78 
trivial_face_list() (function), 80 
TRUE (macro), 11 
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try, 269, 271 

try.exe, 269 

tubular surfaces, 203 

Turbo C++ compiler, 73, 279 
Turbo-PASCAL, 284 

Turn over screen pages, 96 
Turn_vec (macro), 37 

twelve bit integers, 256 
Twist (global variable), 38 
two-dimensional array, 65, 195 
two-dimensional geometry, 1 
two-eyed seeing, 25 

type conversion, 283 

type definition, 283 

type of a variable, 5 
Types.h, 3 


u-lines, 205, 240 

Ubyte (type definition), 60 
Ulong (type definition), 257 
UndoT2 (macro), 107 
unequivocal, 143 

unit, 284 

unit vectors, 2 

Unix C compiler, 277 

UNIX environment, 259, 269 
UNIX function, 59 


USE.SOAP_BUBBLES (macro), 


140 
Ushort (type definition), 196 
uzp, 267 
uzp.c, 267 
uzp.exe, 267 


v-lines, 205, 240 
var (PASCAL keyword), 8 
variable 
declaration, 18 
local, 18 
Vec (type definition), 160 
Vec_mult.matriz (macro), 21 
vec_mult_matria() (function), 
21 
Vector (type definition), 5 
vector, 1 
length, 9 
non-zero vector, 9 
normalization, 9 
scaling, 9 
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vector equation, 2 

vector field, 249 

Vector2 (type definition), 13 

Vertex (type definition), 119 

vertex list, 86 

VGA-Card, 96 

VIDEO, 268, 271 

video, 268 

video file, 271 

video files, 256 

video memory, 97, 99 

« Video_file (global variable), 
257 

viewing frustum, 30 

viewing pyramid, 30 

visibility test, 195 

visible zone, 190 


water, 184 

weighted linear combination, 
243 

which_obj_is_first() (function), 
141 


Which_side (macro), 16 

Window-height (global variable), 
40 

Window-opened (global vari- 
able), 58 

Window-width (global variable), 
40 

Windows, 269 

working directory, 268 

world system, 26, 43, 63, 173 

world_to_light() (function), 42 

world_to_screen() (function), 40 

write_datafile() (function), 93 


X (macro), 7 

X 1_grid (global variable), 198 
X_mid (global variable), 40 
XOR line, 117 

XOR-lines, 46 

ry-_region() (function), 45 
(*zyz)() (function pointer), 224 
ryz_torus() (function), 225 


Y (macro), 7 
Y1_grid (global variable), 198 
Y_mid (global variable), 40 





Z (macro), 7 

z-buffering, 231 

z-buffering, 195 

z.buffer() (function), 196 

Z-buffering (global variable), 
196 

Z-in_screen (macro), 116 

z.region() (function), 47 

z.value() (function), 198 

Zbuf (global variable), 196 — 

zero manifold, 213 

zero of a function, 216 

zero_manifold_of_f_uv (function), 
222 

zero_of.cubic_par() (function), 
217 


zero.of.f-xwith_bin_search() (fun 
tion), 216 

zero.of-f-z-with_newton() (func- 
tion), 216 

Zero_vec (macro), 245 

zp, 267 

zp.c, 267 

zp.exe, 267 


